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ABSTRACT 


Systems  Engineering  is  a  profession,  a  philosophy  and  a  discipline  that 
adopts  an  iterative  and  parallel  problem  identification  and  solution  seeking 
process,  coupled  with  a  collaborative  and  integrated  multi-disciplinary  approach. 
It  involves  the  lifecycle  view  of  deriving  functional  solutions  to  the  identified 
problems  of  the  whole  system  and  its  dependants.  The  end  state  is  in  the 
satisfaction  of  the  requirements,  timeline  and  budget  by  the  stakeholders. 
Systems  Engineering  requires  the  Systems  Engineer  to  possess  a  series  of  traits 
that  are  academically  and  experientially  acquired.  The  thesis  looked  at  capturing 
these  traits  required  via  fuzzy  logic  scales  and  learning  curve.  The  key 
observation  was  in  the  emphasis  and  need  for  certain  traits  at  various  levels  of 
experience  in  the  maturity  cycle  of  a  systems  engineer.  Learning  curves  were 
plotted  to  understand  some  of  these  traits.  The  experiential  fuzzy  logic  scale 
developed  was  used  to  draw  a  relation  to  traits  as  desired  in  an  employment  of  a 
Systems  Engineer.  Using  the  studies  from  the  literature  reviews  on  learning 
curves,  various  learning  curves  were  obtained  for  selected  traits.  For  the 
differences  in  the  start  point,  i.e.  when  these  traits  are  desired  in  an  employment 
of  a  Systems  Engineer,  there  is  a  relationship  between  the  power  and  coefficient 
of  the  curves  to  the  start  point. 
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I.  INTRODUCTION 


A.  OVERVIEW 

It  is  often  observed  that  skilled,  practicing  Systems  Engineers  perform 
more  efficiently  and  more  effectively  than  novices.  They  are  also  better  at 
analyzing  systems  via  reductionism  (i.e.,  the  decomposition  of  the  system)  and 
through  their  respective  functions.  However,  the  challenges  in  adapting 
traditional  techniques  for  modeling  behavior  in  complex  domains  confront  both 
experienced  and  inexperienced  people.  Instructing  first-time  students  in 
functional  analysis  is  both  vital  and  extremely  unintuitive.  Functional  analysis 
allows  the  students  to  understand  an  unknown  system  via  an  appreciation  of  its 
functions.  From  the  functional  analysis,  the  systems  engineer  can  understand  the 
linkages  to  the  functions  and  physical  components. 

Systems  Engineering  is  a  discipline  that  requires  one  to  be  equipped  with 
an  integrated  level  of  knowledge  to  be  of  value  to  the  project.  It  encompasses 
lifecycle  issues,  brings  to  bear  the  constraints  and  boundaries  of  systems 
thinking,  and  includes  all  lifecycle  considerations  that  are  significant  to  the 
success  of  the  project.  The  main  aim  of  Systems  Engineering  is  to  amalgamate 
individual  components  into  a  system  entity  (solution)  that  meets  all  requirements. 
Systems  Engineering  offers  a  structured,  logical  approach  to  achieving  such  an 
objective.  With  the  use  of  the  various  Systems  Engineering  tools  and  processes, 
the  experienced  Systems  Engineer  multiplies  his/her  worth  on  the  project,  as 
he/she  has  a  better  appreciation  of  how  the  system  functions  through  its  sub 
functions. 

Who  is  this  experienced  Systems  Engineer?  What  experience  or 
mentoring  chain  has  he/she  undergone  to  be  what  he/she  is  today?  A 
relationship  between  various  variables  and  the  specific  traits  of  a  Systems 
Engineer  is  offered  in  this  thesis. 
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1. 


Questions 


This  thesis  investigates  what  it  takes  to  be  a  good  Systems  Engineer,  by 
analyzing  their  goals.  The  following  questions  were  addressed: 

1 .  What  makes  a  good1  Systems  Engineer? 

2.  What  are  the  desired  traits  of  a  good  Systems  Engineer? 

3.  What  are  the  traits  that  companies/organizations  look  for  in  their 
employment  of  a  Systems  Engineer? 

4.  What  are  the  key  areas  in  which  a  novice  Systems  Engineer  could  be 
trained  to  become  better? 

5.  How  large  is  the  gap  that  exists  between  a  novice  and  a  good  Systems 
Engineer? 

6.  Can  a  model  be  built  to  characterize  the  essential  traits  of  a  good 
Systems  Engineer? 

7.  Can  a  learning  curve  be  constructed  for  the  traits  of  a  Systems 
Engineer? 

2.  Hypothesis 

The  thesis  begins  by  establishing  two  driving  hypotheses,  namely: 

a.  Hypothesis  #1 

There  is  a  knowledge/ability  gap  between  novice  and  expert 
Systems  Engineers. 


1  A  Good  Systems  Engineer  is  defined  as  one  who  is  able  to  meet  requirements  as  stipulated 
by  the  customer,  meet  schedule  and  one  that  is  able  to  adhere  to  the  allocated  budget. 
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b.  Hypothesis  #2 

The  gap  between  novice  and  expert  Systems  Engineers  can  be 

overcome. 

3.  Motivation 

Other  studies  have  investigated  the  criteria  for  successful  System 
Engineers  in  comparison  with  other  system  professionals.  Some  researchers 
have  examined  the  nature  of  acquiring  knowledge  via  learning  curves.  Frank, 
Frampton,  and  Di  Carlo  (2007)  compared  Systems  Engineers  to  Systems 
Architects  and  IT  Architects,  covering  the  traits  required  by  each  of  these 
professions.  Davidz  (2005)  and  Frank  (2000)  covered  the  aspect  of  the  Systems 
Engineer  having  embedded  Systems  Thinking.  Sheard  (1996)  postulated  twelve 
roles  governing  the  Systems  Engineer,  while  Andress  (1954)  and  Towill  (1985; 
1990)  covered  various  aspect  of  learning  and  their  depiction  with  learning  curves. 

There  is  a  need  to  understand  the  traits  that  are  required  by  a  Systems 
Engineer  as  he  progresses  along  his  profession.  This  thesis  encompasses  a  list 
of  required  traits  for  a  Systems  Engineer. 

B.  BACKGROUND 

Riehle  (2008)  looked  at  various  definitions  of  Engineering  as  captured  by 
a  variety  of  authors.  From  these,  he  encompassed  a  list  consisting  of  sixteen 
concepts  and  practices  that  characterize  Engineering.  These  sixteen  elements, 
taken  as  a  compound,  differentiates  engineering  from  other  disciplines.  His 
purpose  to  define  a  modern  definition  of  Engineering  was  to  allow 
accommodation  of  ‘emerging  engineering  practices  and  not  just  the  traditional 
engineering  disciplines’.  This  led  to  his  proposed  modern  definition  of 
Engineering: 

Engineering  is  the  organization,  application,  and  management  of 
settled  (dependable)  knowledge  using  the  tools  of  science, 
mathematics,  and  logic,  along  with  knowledge,  experience,  and 
artifacts  derived  from  previous  engineering  efforts,  for  reconciling 
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conflicting  forces/constraints,  controlled  within  defined  tolerances, 
to  effect  an  economical,  risk-averse,  maintainable,  fault-tolerant 
design  toward  the  goal  of  a  predictable  outcome. 


Systems  Engineering  is  an  Engineering  Discipline.  Systems  Engineering 
was  combined  from  the  field  of  Value  Engineering  (1945)  and  systems  thinking 
that  was  evolving  in  the  1950s  (Langford,  et.al,  2008).  The  generally  credited 
time  frame  for  the  development  of  the  discipline  of  Systems  Engineering  is  the 
mid  1960s,  and  as  such  it  is  a  fairly  young  field.  This  can  be  illustrated  with  the 
evolution  of  Systems  Engineering  in  Figure  1  which  illustrates  how  Systems 
Engineering  has  been  covered  by  various  authors  throughout  the  decades. 
Commensurate  with  the  Systems  Engineering  timeline  are  the  various  industrial 
and  government  directives  that  either  resulted  in  or  precipitated.  . 

1950  1955  1960  1965  1970  1975  1980  1985  1990  1995 


1995 


Figure  1  Evolution  of  Systems  Engineering  (After:  Brill,  1998) 


Studies  have  also  defined  and  discussed  the  traits  of  a  Systems  Engineer 
(Sheard,  1996;  Davidz,  2005;  Jansma  and  Jones,  2006).  There  seems  to  be 
general  agreement  on  a  list  of  essential  traits  for  a  Systems  Engineer  that  are 
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sought  after  by  today’s  employers,2  as  well  as  being  desired  by  practicing  Senior 
Systems  Engineers.3  Generally,  these  two  lists  are  highly  correlated. 

This  common  set  of  traits  is  necessary  to  conduct  the  activities  required  to 
do  Systems  Engineering  on  a  project.  Examples  of  these  traits  include  the  ability 
to  perform  requirements  analysis,  testing,  and  interfacing,  among  others.  This 
thesis  identified  a  list  of  parameters  and  measures/metrics  that  govern  the 
required  traits  of  a  Systems  Engineer. 

There  are  many  different  permutations  today  that  define  Systems 
Engineering,  with  broad  statements  that  overlap.  Such  common  themes  as 
interdisciplinary  subject,  iterative  process,  and  systems  approach,  are  among  the 
most  frequently  described.  One  possible  reason  for  the  diversity  for  the  definition 
of  Systems  Engineering  is  offered  by  Kasser  and  Massie  (2001).  They  cite 
differences  in  the  operating  levels  of  the  systems  engineers  as  a  primary 
determinant  of  the  differences.  As  different  operating  levels  grow,  the  usage  of 
different  vocabulary  results  in  a  variety  of  definitions.  Despite  the  operations  at 
the  these  different  levels,  the  task  being  performed  encompasses  the  processes 
of  Systems  Engineering. 

The  definition  of  Systems  Engineering  was  determined  by  surveying  the 
plethora  of  definitions  and  determining  a  taxonomy.  This  compendium  of  28 
definitions  is  found  in  Appendix  A.  The  variety  of  definitions  could  imply  the 
existence  of  a  variety  of  traits  required  to  perform  Systems  Engineering.  All  the 
definitions  were  bonded  to  refer  to  the  traits  of  a  Systems  Engineer.  The  thesis 
lists  these  essential  traits  of  a  systems  engineer.  This  goes  on  to  the  possible 
implication  that  at  different  levels,  denoted  by  the  years  of  experience  of  a 
Systems  Engineer,  different  traits  may  be  required.  Concurrently,  there  are  some 
similarities  and  additions  to  these  definitions  over  the  different  periods 


2  This  can  be  found  in  the  list  of  traits  of  a  Systems  Engineers  extracted  from  the  study  of 
classified  ads  as  part  of  the  research  for  this  thesis. 

3  As  part  of  this  research,  a  survey  was  conducted  of  practicing  Systems  Engineers  in  the 
Academic  and  Industry  arenas  to  ascertain  their  views  on  what  makes  a  Good  Systems  Engineer. 
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considered  (1960s  to  2000s).  This  possibly  implies  that  there  are  Systems 
Engineering  activities  being  carried  out  over  the  decades  that  have  not  changed. 
As  we  progressed  over  time,  we  refine  the  definition  to  emphasize  other  activities 
within  Systems  Engineering.  This  thesis  will  show  that  with  different  years  of 
experience  of  a  Systems  Engineer,  different  traits  are  required. 

This  section  of  the  background  of  Systems  Engineering  looks  at  the 
questions  posed  in  Figure  2: 


1.  In  the  Beginning.... 

When  God  wanted  Noah  to  build  an  Ark,  He  had  a  plan.  He  had 
considered  what  was  to  be  done  and  systematically  gotten  Noah  to  construct  the 

Ark  that  would  preserve  his  family  and  a  breed  of  every  animal.  This .  is 

Systems  Engineering  in  practice. 
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To  claim  the  first  original  use  of  the  term  Systems  Engineering,  Hall 
(1962),  goes  on  to  mention  that  the  term  was  first  coined  and  used  by  Bell 
Laboratories  in  the  1940s.  He  goes  on  to  mention  that  the  first  attempt  to  formally 
teach  the  Systems  Engineering  was  made  in  1950  at  the  Massachusetts  Institute 
of  Technology  by  Mr.  G.  W.  Gilman,  then  Director  of  Systems  Engineering  at  Bell 
Laboratories,  Inc. 

On  the  other  hand,  Kossiakoff  and  Sweet  (2003)  and  Brill  (1998)  highlight 
the  lack  of  a  period  to  be  correlated  to  the  origins  of  Systems  Engineering. 

2.  Why  the  Need  for  Systems  Engineering? 

Given  a  context,  system  engineering  establishes  a  framework  to 
support  a  process  with  which  we  practice  with  consistency  and, 
hopefully,  completeness....  (Boarder,  1995) 


As  in  the  process  of  Systems  Engineering,  it  is  necessary  to  identify  the 
need  for  a  particular  situation,  based  on  the  problem  that  needs  to  be  rectified. 

Table  1  Summary  for  the  Need  for  Systems  Engineering 


S/N 

Source 

Why  the  Need 

1 

Parnaby  (1995), 
then  President  of 
Luca  Industries 

The  complexities  of  today’s  products  and  the 
techniques  needed  to  make  them  have  made 
Systems  Engineering  methods  essential  to  effective 
competition 

2 

Lewkowicz 

(1998) 

Very  large  integrated  systems  have  always  posed 
special  problems  for  engineers.  "Systems 
Engineering"  has  evolved  as  a  discipline  in  order  to 
meet  these  challenges  by  providing  a  structured,  top- 
down  design  and  development  methodology  for  the 
engineer. 

3 

Barber  (1998) 

Systems  Engineering  is  at  the  heart  of  product 
development  and  improving  the  performance  of  this 
discipline  is  key  to  organizational  success 
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S/N 

Source 

Why  the  Need 

4 

Chiang  (2003) 
adapted  from 
Arthur  (1993) 

Fast  occurring  changes,  broad  impacts,  non  linear 
interactions.  Overall,  the  drive  is  for  a  strong 
profession  that  is  structured  and  ordered  in  its 
approach  to  complex  systems 

5 

Honour  (2004) 

The  results  of  the  study  indicate  that  optimal  SE  effort 
is  approximately  15  to  20%  of  the  total  project  effort. 

6 

Goncalves 

(2008) 

Systems  Engineering  is  a  critical  capability  for  our 
organization’s  business  following  good  growth  in 
business  but  also  because  of  risks  in  certain  areas 

Table  1  outlines  the  various  citations  on  the  need  for  Systems 
Engineering.  Systems  Engineering  is  needed  for  its  ability  to  deal  with  complex 
systems  thus  leading  to  the  sustainment  of  the  industry’s  competitive  advantage 
with  the  structured  process. 

Systems  Engineering  emerged  due  to  the  need  to  solve  the  problems  of 
the  integration  of  hardware  and  software  issues  in  Software  Engineering.  To 
name  a  few,  the  activities  involved  in  the  process  allowed  the  systematic 
consideration  of  issues  like  stakeholders  identification,  requirements  identification 
and  integration  parameters  to  be  carried  out.  This  allowed  the  complexity  of  the 
integration  between  hardware  and  software  to  be  managed  (Langford,  2008). 

3.  Why  is  the  Government  Involved? 

The  need  for  Systems  Engineering  is  evident  from  the  intervention  of  the 
U.S.  Department  of  Defense  in  creating  standards  to  assist  in  the  embracement 
of  Systems  Engineering  for  the  weapons  acquisition  process. 

With  the  growth  of  industrialization  after  World  War  II,  systems  grew  to 
complexity.  As  such,  the  processes  and  tools  as  offered  by  Systems  Engineering 
were  deemed  to  be  useful  in  dealing  with  these  systems.  The  post-World  War  II 
period  saw  the  experiences  and  lessons  acquired  during  the  war  being  used  for 
the  newer  acquisition  for  defense.  Systems  Engineering  was  tagged  as  a  useful 
component  for  the  acquisition  of  these  weapons  systems. 
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As  depicted  in  Figure  1  the  publication  of  the  Air  Force  Systems 
Command  Manual  375-5  (AFSCM  375-5),  System  Engineering  Management 
Procedures  in  1966: 

...prescribes  the  management  policies  and  procedures  to  be 
followed  in  the  establishment  of  requirements  for,  and  in  the  design, 
development,  test,  operation,  and  maintenance  of  future  Air  Force 
systems...  (Gelbwaks,  1967) 


With  the  AFSCM  375-5,  the  military  standards  and  industrial  standards 
arena  saw  subsequent  introduction  of  other  standards  on  the  practice  of  Systems 
Engineering  for  systems.  Led  by  the  U.S.  Air  Force  (shown  in  Table  2),  who  was 
responsible  for  the  development  of  satellites,  the  U.S.  Air  Force  developed  the 
Systems  Engineering  Management  Procedures  in  order  to  promulgate  the 
practice  of  Systems  Engineering  for  their  complex  satellite  building  efforts. 


Table  2  Genealogy  of  Systems  Engineering  Military  Standards  and 
Handbook  (Adapted  from  Brill,  1998) 


S/N 

Standard  / 
Handbook 

Origins 

Contents 

1 

Handbook  375-5 
(1966)  -  System 
Engineering 
Management 
Procedures 

U.S.  Air  Force 

Describes  in  great  detail  a 
Systems  Engineering  process. 

2 

MIL-STD-499 
(1969)  -  Systems 
Engineering 
Management. 

U.S.  Air  Force 

The  standard  superseded  the 
“how-to”  content  of  375-5  and 
was  intended  to  assist 
Government  and  industry  in 
defining  the  Systems 

Engineering  effort  of  defense 
acquisition  programs. 
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S/N 

Standard  / 
Handbook 

Origins 

Contents 

3 

MIL-STD-499A 

(1974) 

U.S.  Air  Force 

A  revision  to  MIL-STD-449  to 
provide  program  managers 
criteria  for  evaluating 

engineering  planning  and 
output,  a  means  for 

establishing  an  engineering 
effort  and  a  Systems 

Engineering  Management  Plan 

(SEMP). 

4 

U.S.  Army 
published  Field 
Manual,  770-78 
(1979)  -  Systems 
Engineering. 

U.S.  Army 

The  manual  describes  a 
system  engineering  process 
and  presents  extensive 

Systems  Engineering  “how-to” 
guidelines  for  implementing  a 
Systems  Engineering  process 
and  managing  system 

engineering. 

5 

MIL-STD-499B 
(1992)  -  Systems 
Engineering 
Handbook 

U.S.  Air  Force 

The  standard  provided  a  more 
comprehensive  description  of  a 
Systems  Engineering  process 
and  its  management  to  include 
an  outline  for  a  Systems 
Engineering  Management  Plan 
(SEMP). 

The  successes  (and  failures)  achieved  over  the  years  on  the  use  of 
Systems  Engineering  in  the  U.S.  Department  of  Defense  resulted  in  a  memo4 
issued  on  30  March  2004,  which  stated  that: 

...All  programs  responding  to  a  capabilities  or  requirements 

document . shall  develop  a  Systems  Engineering  Plan  (SEP)  for 

Milestone  Decision  Authority  (MDA)  approval  in  conjunction  with 
each  Milestone  review . 


4  Retrieved  on  30  Sep  08  -  Implementing  Systems  Engineering  Plans  in  D0D  -  Interim 
Guidance.  http://sepo.spawar.navy.mil/lmplementing_SE_PlansJn_DoD_lnterim_Guidance.pdf 
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4. 


Where  are  we  Headed  ? 


It  is  certain  that  the  systems  being  managed  will  become  more  complex  in 
the  future.  There  will  be  a  need  for  the  Systems  Engineer  to  manage  these 
increasingly  complex  systems.  Therefore,  the  required  Systems  Engineering 
tools  will  need  to  be  more  robust. 

Booton  and  Ramo  (1984)  observed  that  Systems  Engineering  will 
progress  in  the  direction  of  increased  capabilities  of  analytical  tools  used  by 
Systems  Engineers  and  will  increase  in  complexity  following  the  systems  under 
consideration. 

Mintz  (1994)  covered  the  growing  complexity  of  the  systems  faced  and 
thus  the  need  for  developing  Systems  Engineering  techniques.  He  stated  that 
Systems  Engineering  will  be  developed  via  use  of  computer-aided  Systems 
Engineering  tools  that  support  the  Systems  Engineering  Process,  formalize 
specification  models,  and  merge  commercial  and  Department  of  Defense 
standards.  This  amalgamation  responds  to  an  increase  in  the  commercial  and  a 
decrease  in  the  government  businesses,  third-party  evaluation  and  certification  of 
processes  and  professional  recognition  of  Systems  Engineers. 

From  the  perspective  of  learning  from  the  problems  of  Systems 
Engineering,  Bar-Yam  (2003),  suggested  two  strategies  of  confining  conventional 
Systems  Engineering  processes  to  “not-too-complex”  projects  and  “an 
evolutionary  paradigm  for  complex  Systems  Engineering  that  involves  rapid 
parallel  exploration  and  a  context  designed  to  promote  change  through 
competition  between  design  implementation  groups  with  field  testing  of  multiple 
variants”. 

In  addressing  the  tools  required  for  growing  complexity,  Chiang  (2003) 
talked  about  the  Systems  Engineering  support  tools  evolving  and  how  these  tools 
can  subsequently  contribute  to  the  scientific  study  of  complexity. 
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Boarder  (1995)  added  that: 


Given  a  context,  system  engineering  establishes  a  framework  to 
support  a  process  with  which  we  practice  with  consistency  and, 
hopefully,  completeness. 


5.  Tomorrow’s  Systems  Engineers...  Handle  Complexity 

The  nature  of  tomorrow’s  systems  are  complex. 

Using  the  classical  approach  to  tackle  a  problem  may  subsequently 
require  additional  ‘support  tools’.  Chiang  (2003)  recommended  expanding  the 
role  of  Systems  Engineers  to  handle  more  complex  systems  to  prepare  for 
tomorrow. 

Chen  and  Clothier  (2003)  outlined  the  need  for  improving  via 
complementing  the  current  Systems  Engineering  process  with  practices  of 
concurrent  engineering,  consideration  of  a  Systems  Engineering  infrastructure, 
and  modern  Systems  Engineering  management  for  engineering  activities  and 
data  /  information  across  projects  and  systems  domains.  These  would  assist  the 
organization  and  management  to  deal  with  the  high  complexity  of  systems 
“evolutions  and  improve  its  architecture  practice”. 

Dahmann  and  Baldwin  (2008)  went  on  to  mention  that  the  U.S. 
Department  of  Defense  has  recognized  the  need  to  “manage  and  engineer 
ensembles  of  systems  to  address  use  capability  needs”  due  to  the  increased 
complexity  of  tomorrow’s  systems. 

C.  METHODOLOGY  OF  THESIS 

The  methodology5  section  will  cover  the  activities  associated  with  the 
thesis,  the  methodology  used  and  the  implications  associated  with  that 
methodology. 

5  Definition  of  methodology  -  A  System  of  Methods  and  Rules  to  facilitate  the  collection  and 
analysis  of  data.  (Hart,  1998) 


12 


1.  Methodology  Overview 

A  qualitative  approach  in  acquiring  and  managing  the  data  was  used  for 
this  analysis.  A  quantitative  tool  was  used  to  examine  and  evaluate  the  data. 

The  qualitative  approach  was  intended  to  sort  the  acquired  traits  of  a 
Systems  Engineer  relative  to  two  variable,  i.e.  years  of  experience  and  annual 
income.  Quantifying  the  SE  traits  challenged  the  traditional  means  of  analysis 
due  to  their  overlap  and  underlap  in  defining  properties.  Therefore,  a  fuzzy  logic 
approach  was  used  to  understand  the  relative  quantization  of  these  traits. 

An  overview  of  the  activities  covered  by  the  thesis  spans  history,  analysis, 
and  common  platform,  that  of  a  three-pronged  approach,  as  depicted  in  Figure  3. 
The  methodology  can  be  referred  to  in  Figure  4.  A  triangulation6  (Silverman, 
2005)  method  of  comparison  was  used  to  corroborate  the  various  data  collected 
from  the  classified  ads,  surveys  and  literature  review.  The  method  of  triangulation 
was  that  used  by  Frank,  Frampton,  and  Di  Carlo  (2007). 

In  the  process  of  establishing  a  methodology  for  the  thesis,  a  Systems 
Engineering  approach  was  taken  to  consider  the  different  set  of  activities 
required  in  establishing  the  process  to  be  taken.  This  is  depicted  in  Figure  5.  The 
process  involved  a  set  of  activities,  coupled  with  inputs  and  outputs  from  each 
process.  A  set  of  interrelationship  was  established  within  this  process,  between 
the  activities,  inputs  and  outputs.  Worth  mentioning,  it  was  established  that  the 
Literature  Review  was  an  important  input  to  be  used  at  almost  all  of  the  activities 
in  the  process.  This  was  essentially  true  as  information  from  the  varied  sources 
(shown  in  Figure  8  page  26)  allowed  the  activities  to  be  performed  to  develop  the 
desired  output. 


6  Triangulation  -  the  comparison  of  different  kinds  of  data  (quantitative  and  qualitative)  and 
different  methods  (e.g.,  observation  and  interviews)  to  see  whether  they  corroborate  one  another 
(Silverman,  2005,  p.  380). 
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The  methodology  for  this  thesis  covers  the  need  to  have  the  required  data 
(traits)  for  the  initial  start  up.  This  was  obtained  via  different  data  sources,  such 
as  classified  ads,  surveys  sent  to  practicing  Systems  Engineers  and  the  literature 
reviews  conducted. 

Data.  The  data7  gathering  phase  was  deemed  to  be  complete  once  a 
noticeable  pattern  evolved  in  each  of  the  three  data  gathering  modes.  This  is 
akin  to  the  method  of  doing  a  meta  analysis,  less  the  presence  of  any  statistical 
comparison.  The  noticeable  pattern  evolution  was  similar  to  the  idea  given  by 
Silverman  (2000),  on  the  establishment  of  categories  (outstanding  repeated 
elements)  in  the  analysis  of  raw  data.  Frank,  Frampton  and  Di  Carlo  (2007)  also 
used  this  idea  in  their  paper. 

In  the  use  of  the  classified  ads  to  gather  data  of  the  traits  of  a  Systems 
Engineer,  a  relationship  finding  mode  was  used  in  order  to  establish  possible 
relationship  between  the  traits  and  the  variables  of  income  and  years  of 
experience. 


7  Definition  of  Data  -  the  traits  of  the  Systems  Engineer,  years  of  experience  of  the  Systems 
Engineer  with  the  associated  traits,  annual  income,  definitions  of  Systems  Engineering.  The 
sources  of  these  data  were  the  classified  ads,  survey  and  literature  review. 
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Figure  3  Activities  of  Thesis 


Figure  4  Methodology  of  Thesis 


15 


Survey 


Emails 


Literature  Review 


Develop 

Questions 


Stakeholders 

Need 

Problem 

Thesis  (Problem) 

Analyze  Data 

Analysis 

Statement 

4 - ► 

Statement 

*4 - ► 

Requirements 

; 

: 

Identification  of 

Stating  the 

Stakeholders 

Solution 

Problem 

\ 

- f 

* 

Identification  of 
the 

Requirements 


Functional 

Decomposition 


Literature  Review 


Measurements 


Construct 

Research 

Approach 


System 

Modeling 


Model  of 
Maturity  Curve 


Fuzzy  Logic 


Conduct 

Research 


Prc 

Mana 

ject 

gement 

J 

r 

Documentation 

Thesis  Report 


Draft  Thesis 


Final  Thesis 


Submission 

Signatories 


Figure  5  Systems  Engineering  Activities 


16 


‘Modified’  Text  Mining.  The  definition  of  text  mining  is  offered  below: 


Text  mining  tries  to  solve  the  crisis  of  information  overload  by 
combining  techniques  from  data  mining,  machine  learning,  natural 
language  processing,  information  retrieval,  and  knowledge 
management.  (Feldman  and  Sanger,  2006) 


The  idea  of  text  mining  was  adopted  to  manage  the  large  number  of  traits 
that  would  be  expected  to  be  retrieved  from  the  survey,  classified  ads  and 
literature  review.  The  modification  here  refers  to  the  absence  of  the  use  of  any 
automated  system  in  the  collection  of  the  naturally  occurring  text. 

Scaling  Tools.  Several  possible  scaling  tools  were  listed  in  order  to 
ascertain  their  suitability  to  conduct  scaling  of  the  gathered  categorized  data. 
Examples  included  Multi-Dimensional  Scaling  (MDS),  Quality  Functional 
Deployment  (QFD),  Hilbert  Space  and  Fuzzy  Logic.  The  sole  task  of  these  tools 
was  in  the  quantifying  of  the  gathered  traits  against  another  variable,  e.g.  years 
of  experience  or  annual  income. 

Fuzzy  Logic  was  chosen  as  a  good  overview  of  the  gathered  traits  that 
could  be  visually  seen  on  a  given  arbitrary  quantitative  scale.  The  implication  of 
this  selection  showed  some  possible  error  term,  which  is  discussed  in  the 
Implications  of  Methodology  of  Thesis  Section  (p.  18).  Fuzziness  implies  that 
there  is  no  clear  demarcation  of  boundaries  within  a  collection  of  objects,  as 
opposed  to  the  concept  of  dichotomy,  where  clear  sets  of  boundaries  exist 
(Pedrycz  and  Gomide,  2007). 

Outputs.  Once  the  data  gathering  and  scaling  tool  selection  was 
done,  attributes,  relationships,  numerical  scaling  and  applications  were  looked 
into  while  creating  the  various  fuzzy  scales.  These  were  considered  as  the  output 
for  the  thesis  where  the  traits  and  some  gathered  variables  (e.g.  years  of 
experience,  annual  income)  were  scaled  in  the  chosen  scaling  tool  and  the 
applications  of  these  relationships  looked  into.  As  associated  with  the  scaling 
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tools,  the  selection  of  the  scaling  tool  showed  some  possibly  error  term,  being 
elaborated  in  the  Implications  of  Methodology  of  Thesis  Section  (p  18). 

2.  Linking  Research  Questions  and  Methods 

Mason  (2006)  offers  a  simple  way  of  linking  the  research  questions  to  the 
methods  of  data  exploration.  Table  3  outline  this  linkage  between  the  research 
questions  for  this  thesis  and  the  methods  used: 

3.  Implications  of  Methodology  of  Thesis 
a.  Error  Term 

Within  the  scaling  option  chosen  (i.e.,  Fuzzy  Logic),  it  was 
inevitable  that  a  possible  standard  deviation  would  exist  within  the  scale  used; 
this  was  identified  as  a  possible  source  of  error.  A  squared  summation  of  the 
error  was  rooted  in  order  to  appreciate  the  associated  error.  As  such,  the  reader 
is  advised  to  associate  the  number  of  years  of  experience  for  a  given  trait  with 
this  associated  error.  The  associated  error  is  given  as: 


^  ,  ,  „  .  ,  (Interval  Size#1)  +(lnterval  Size#,)  + . +(lnterval  Size#.) 

Standard  Deviation  (Error  Term)  =  1 - m ^ 


Standard  Deviation  (Error  Term)  = 


(2)  +(3)  +(5) 


Standard  Deviation  (Error  Term)  «  3.6  years 


The  fuzzy  logic  scale  thus  used  has  an  associated  error  term  of  about  3.6 

years. 


b.  Usage  of  Classified  Ads  for  Traits  Requirement 

The  requirements  of  a  Systems  Engineer  as  printed  in  the  classified 
ads  were  chosen  to  allow  the  data  to  be  as  ‘naturally  occurring’  (Silverman, 
2005)  as  possible,  without  any  special  setup  of  interviews  and  specific 
environments. 
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In  the  use  of  the  classified  ads  as  a  means  to  collect  the  desired 
traits  of  a  Systems  Engineer,  it  was  assumed  that  the  originator  was  well  versed 
in  the  desired  requirements.  The  Use-Case  model  of  the  Job  Application  process 
is  shown  in  Figure  6.  The  basic  set  of  actors  in  this  process  are  the  job  applicant 
and  the  HR  Manager  (assumed  to  be  the  originator  of  the  ad).  The  HR  Manager 
understands  the  needs  of  the  company  and  crafts  the  job  requirements  (possibly 
with  another  Systems  Engineer).  These  requirements  are  then  advertised.  The 
job  applicant  understands  the  basic  requirements  as  set  out  in  the  advertisement, 
and  submits  an  application.  If  the  application  is  reviewed  favorably,  an  interview 
is  set  up. 

Further  on,  an  ‘Overlap  Theory’  was  developed  with  regard  to  the 
various  scenarios  that  the  hiring  process  can  engender.  This  is  depicted  in  Figure 
7. 

The  various  scenarios  depict  the  hiring  and  non-hiring  situations. 
The  hiring  process  involves  a  certain  degree  of  overlapping  of  the  requirements 
mentioned  in  the  classified  ads  and  the  abilities  of  the  applicant,  ranging  from  0% 
to  possibly,  100%. 


Table  3  Linking  Research  Questions  to  Methods  (After:  Mason,  2006) 


S/N 

Research  Question 

Data  sources 

Justification 

1 

What  makes  a  good 
Systems  Engineer? 

•  Surveys 

•  Literature 
Review 

•  Survey  will  provide  the 
industrial  experience  of 
the  respondents  of 
successful  Systems 
Engineers 

•  Literature  Review  will 
contain  results  of  studies 
or  surveys  conducted  on 
successful  Systems 
Engineers 
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S/N 

Research  Question 

Data  sources 

Justification 

2 

What  are  the  desired 
traits  of  a  good  Systems 
Engineer? 

•  Surveys 

•  Literature 
Review 

•  Surveys  will  serve  as  a 
means  to  seek  the 
opinions  of  the 
respondents  on  traits  of 
a  good  Systems 

Engineer 

•  Literature  Review  will 
contain  results  of  studies 
or  surveys  conducted  on 
successful  Systems 
Engineers 

3 

What  are  the  traits  that 
companies/organizations 
look  for  in  their 

employment  of  a 

Systems  Engineer? 

•  Surveys 

•  Classified 

Ads 

•  Survey  results  will  give 
an  indication  of  the 
desired  traits,  since  the 
respondents  chosen  are 
practicing  Systems 
Engineers 

•  The  requirements  in  the 
Classified  Ads  for 

Systems  Engineers 
reflect  the  desired  traits 

4 

What  are  the  key  areas 
in  which  a  novice 
Systems  Engineer  could 
be  trained  on  to  become 
better? 

•  Classified 

Ads 

•  Fuzzy  Logic 
Experiential 
Scale 

•  Classified  Ads,  with  the 
output  of  the  Fuzzy  Logic 
Experiential  Scale,  will 
chart  the  difference 
between  experienced 
and  novice  Systems 
Engineers.  This  will  then 
be  used  to  ascertain  the 
differences  in  the  traits 
between  them 

5 

How  large  is  the  gap  that 
exists  between  a  novice 
and  good  Systems 
Engineer? 

•  Classified 

Ads 

•  Fuzzy  Logic 
Experiential 
Scale 

•  Classified  Ads,  with  the 
output  of  the  Fuzzy  Logic 
Experiential  Scale,  will 
chart  the  difference 
between  experienced 
and  novice  Systems 
Engineers.  This  will  then 
be  used  to  ascertain  the 
differences  in  the  traits 
between  them 
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S/N 

Research  Question 

Data  sources 

Justification 

6 

Can  a  model  be  built  to 
characterize  the 

essential  traits  of  a  good 
Systems  Engineer? 

•  Classified 

Ads 

•  Fuzzy  Logic 
Experiential 
Scale 

•  Classified  Ads,  with  the 
output  of  the  Fuzzy  Logic 
Scale,  will  chart 
membership  of  the 
highlighted  variables  of 
annual  income  and  years 
of  experience  of  the 
Systems  Engineer.  This 
will  shed  some  light  on 
the  traits  that  are 
required  at  the  different 
levels  of  experience 

7 

Can  a  learning  curve  be 
constructed  for  the  traits 
of  a  Systems  Engineer? 

•  Literature 
Review 

•  Literature  Review  of 
learning  curves,  traits  will 
assist  to  form  a  construct  to 
the  relationship  between 
the  parameters  in  question. 

Figure  6  Use-Case  Diagram  for  Job  Application 
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NOT  HIRED 


Job  Applicant  HR  Manager 


HIRED 


Figure  7  Various  Scenarios  of  Overlap  Theory 


This  ‘Overlap  Theory’  is  used  to  show  that,  with  the  following 
possible  areas  of  concerns  (Table  4),  the  process  of  advertising  in  the  classified 
ads  does  reveal  some  error  in  the  crafting  of  the  desired  Systems  Engineer 
requirements.  Subsequently,  the  hired  Systems  Engineer  may  possibly  not  have 
the  full  range  of  desired  traits. 
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Table  4 


Areas  of  Concern  for  Classified  Ads 


S/N 

Area  of  Concern 

Details 

Implications 

1 

Need  of 
Organization 

The  office  assigned  to 
comprehend  the  need  of 
the  potential  hired 

Systems  Engineer  may 
misunderstand  the 

intended  need 

Inaccurate 
requirements 
specified  in  ads 

2 

Interpretation  of 
Needs  to 
Requirements 

The  requirements 

statements  may  not  cover 
the  needs  due  to 
misinterpretation 

Inaccurate 
requirements 
specified  in  ads 

3 

Shrinking 
Requirements  to 
Classified  Ads 

Advertising  space  cost 
money.  As  such,  there 
might  be  a  selection  of 
‘only  the  necessary’ 

requirements  to  be 

submitted  for  publication 
in  the  classified  ads 

Inaccurate 
requirements 
specified  in  ads 

4 

Ability  matching  to 
Classified  Ads 

The  applicant  may  try  to 
match  as  many  as 
possible  of  his  abilities  to 
the  requirements  printed 
in  the  classified  ads,  thus 
may  not  fulfill  all  of  them 

May  not  be  the 
suitable  candidate 

hired 
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II.  LITERATURE  REVIEW 


To  demonstrate  skills  in  library  searching;  to  show  command  of  the 
subject  area  and  understanding  of  the  problem;  to  justify  the 
research  topic,  design  and  methodology.  (Hart,  1998,  as  cited  in 
Silverman,  2005) 

After  some  initial  groveling,  know  what  you  are  looking  for. 
Approach  the  literature  with  questions  and  remember  that  your  goal 
is  to  advance  it,  not  simply  to  marvel  at  its  wonders.  Seek  an 
appropriate  balance  between  appreciation  and  advancement  of  the 
literature.  (Marx,  1997,  as  cited  in  Silverman,  2005) 


A.  METHODOLOGY  OF  LITERATURE  REVIEW 

1.  Methodology  of  Literature  Review 

As  in  all  research,  literature  review  is  an  important  phase  where  the  works 
of  the  past  and  the  present  are  given  consideration  and  used  as  data  points  for 
one’s  work.  The  above  two  quotes  clearly  illustrate  the  essence  of  a  literature 
review:  gain  a  thorough  grounding  in  the  subject  area  to  understand  the  problem 
and  advance  what  has  already  been  done  and  considered  by  others.  As  depicted 
in  Figure  5,  Literature  Review  is  the  data  gathering  activity  most  connected  to  the 
other  steps  for  this  thesis. 

Figure  8  outlines  the  sources  used  for  the  literature  review  in  order  to 
establish  a  firm  foundation  to  effectively  evaluate  works  in  relation  to  the  thesis 
(Marx,  1997,  as  cited  in  Silverman,  2005): 
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Seminars  / 
Workshops 
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1  Newsgroup  | 

!  Online  ; 

1  I 
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1  Searches  1 

i  i 

>  i 

1  internet  1 

1 _ 1 

1  l 

•  1 

1 _ 1 

i  i 

•  i 

•  _ i 

Figure  8  Sources  of  Knowledge  for  Literature  Review  (After:  Marx,  1997,  as 

cited  in  Silverman,  2005) 


During  the  survey  conducted  of  practicing  Systems  Engineers  to 
determine  the  ideal  traits  of  the  profession,  additional  source  material  (i.e.,  the 
most  cited  articles/books/papers  on  the  topic)  was  also  obtained.  This  allowed 
the  literature  review  to  encompass  the  most  relevant  content  for  the  research. 
Figure  9  illustrates  the  Identification  Explore  Recognition  Clarify-Referencing  Cite 
(IERC-RC)  literature  methodology  used  for  this  thesis.  The  methodology  is 
iterative  in  nature,  cycling  between  the  IERC  phases  until  a  satisfactory  reference 
is  found.  In  order  to  maintain  a  good  index  of  the  references  found,  a 
management  system  (RefWorks)  was  utilized  to  manage  the  database  of 
references. 
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rite 
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Figure  9  Methodology  for  Literature  Review  (IERC-RC) 


B.  SUMMARY  OF  LITERATURE  REVIEW 
1.  Meta-Visualizing  Tool 

The  snapshot  of  the  Meta-Visualizing  Tool  is  depicted  in  Figure  10.  This 
figure  shows  the  relationship  of  some  of  the  sources  of  literature  review  to  the 
topics  of  consideration  for  the  thesis.  This  tool  allowed  relationships  to  be  drawn, 
thus  allowing  an  understanding  of  the  various  topics  to  each  other. 
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Scaling  Tool 
(Fuzzy  Logic) 

\ 

^Bandemer;  Gottwald,  1995^ 


Pedrycz;  Gomide,  2007 


Zadeh,  1965, 1973 


Figure  10  Meta-Visualizing  Tool  for  Literature  Review 
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C.  READINGS 

This  section  looks  at  the  readings  that  assisted  in  the  classification  of  the 
information  and  the  summarization  of  the  following,  contained  within  those 
readings  (modified  from  Murcott,  1997): 

1 .  What  do  we  know  about  the  topic? 

2.  What  will  the  thesis  say  critically  about  what  is  already  known? 

3.  Has  anyone  done  anything  related  to  the  thesis? 

4.  Where  does  the  thesis  fit  in  with  what  has  been  done  before  and  how 
is  it  beneficial? 

1.  Traits  of  Systems  Engineers 

As  previously  mentioned,  there  has  been,  over  time,  a  compilation  of 
many  articles  and  books  that  cover  the  traits  of  successful  Systems  Engineers. 
The  ability  of  a  Systems  Engineer  to  think  systemically  was  seen  to  be  an 
essential  trait,  as  covered  extensively  by  Baird  (1971);  Frank,  Zwikael  and 
Boasson  (1997);  Frank  (2000);  Augustine  (2000);  Frank  and  Elata  (2005)  and 
Davidz  (2005).  Sheard  (1996)  conducted  further  research  on  the  twelve  possible 
roles  of  a  Systems  Engineer.  There  were  some  variations  where  attempts  were 
made  to  look  at  specialized  Systems  Engineers,  e.g.,  in  Space  Systems  by 
Moore  (2000).  Frank,  Frampton  and  Di  Carlo  (2007)  conducted  comparison 
studies  between  a  Systems  Engineer  and  Systems  and  IT  Architects.  These 
identified  traits  foster  an  understanding  as  to  what  could  possibly  make  a  good 
Systems  Engineer.  As  mentioned  previously,  a  triangular  comparison  (Figure  11) 
was  done  of  those  traits  acquired  from  the  literature  reviews,  those  required  by 
today’s  companies  in  the  classified  ads  and  those  given  in  surveys  by  practicing 
Systems  Engineers.  It  was  noted  that  many  of  the  traits  were  common  to  all  three 
sets  of  gathered  data. 
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With  the  great  body  of  research  done  on  the  required  and  desired  traits, 
the  question  lies  in  the  relationship  of  time  to  the  acquirement  of  these  traits  in 
order  to  be  a  good  Systems  Engineer. 

2.  Systems  Engineering  and  Its  Definition 

In  his  paper  to  the  Proceedings  of  the  17th  International  Symposium  of  the 
INCOSE,  San  Diego,  CA.,  2007,  Kasser  mentioned  that: 

Research  has  shown  that  one  reason  for  the  lack  of  agreement  (of 
the  activities,  roles  and  definition)  is  that  systems  engineers  do 
many  and  different  tasks  in  their  work  and  consequently  have 
different  perspectives  on  Systems  Engineering.  In  addition 
performing  Systems  Engineering  seems  to  be  like  solving  wicked 
problems. 


Systems  Engineering  is  a  discipline  that  requires  interdisciplinary 
knowledge  in  order  for  a  practicioner  to  be  of  value  to  the  project  at  hand.  There 
are  many  different  permutations  today  that  define  what  Systems  Engineering  is 
all  about.  Appendix  A  covers  a  search  for  the  various  definitions  of  Systems 
Engineering,  apart  from  the  definition  offered  by  the  International  Council  of 
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Systems  Engineering  (INCOSE)  (2006).  The  teaching  of  Systems  Engineering  is 
said  to  have  started  in  1950  (Brill,  1998).  A  comparison  was  made  of  the  various 
definitions  of  Systems  Engineering  over  the  years,  since  it  was  first  taught  in  the 
1950s;  this  is  depicted  in  Figure  12,  Figure  13Figure  14.  Figure  15  shows  the 
origins  of  the  definitions. 

From  Figure  12,  Figure  13Figure  14  and  Figure  15,  there  is  an  array  of 
phrases  that  can  be  used  to  define  Systems  Engineering.  In  almost  all  the  cases, 
readers  are  all  too  familiar  with  the  functions  that  are  involved  in  Systems 
Engineering  and  thus  can  relate  to  these  phrases.  In  this  thesis,  the  following 
definition  of  Systems  Engineering  is  used: 


Systems  Engineering  is 
a  profession, 
a  philosophy  and 
a  discipline 

that  adopts  an  iterative  and  parallel  problem  identification  and 
solutioning  process,  coupled  with  a  collaborative  and  integrated 
multi-disciplinary  approach. 

It  involves  the  life-cycle  view  of  deriving  functional  solutions  to 
the  identified  problems  of  the  whole  system  and  its  dependants. 

The  end  state  is  in  the  satisfaction  of  the  requirements,  timeline 
and  budget  by  the  stakeholders. 
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Descriptive  Phrases  of 
Systems  Engineering 


Class  of  Systems 

Application  of  Engineering  Efforts 

Analysis 

Compatibility 

Application  of  Scientific  Efforts 

Broad  Technical  Plan 

Current  Engineering 

Better  Design  of  man -organized  and  man- 

Business 

Development  Planning 

made  systems 

Designing  of  Systems 

Development  Studies 

Comprehending  Complex  Systems 

Formulate  Economic  Objectives 

Exploratory  Planning 

Integration  Process 

Formulates  Operational 

Integrated  Approach 

In  terdisciplinary  Approach 

Performance 

Integration  Process 

Maintenance  Analysis 

Modeling 

Iterative  Process 

Operation  Analysis 

Research 

Optimization  through 

Scientific  Methods 

Simulation 

balancing  objectives 

System  Functional  Analysis 

Program  Planning 

System  Reliability  Analysis 

Recogn  ition  of  System 

Systems  Approach 

Objectives 

Task  Analysis 

System  Approach 

System  Considerations 

System  Studies 

Testing 

Use  of  an  Iterative  Process 

1960s  19705  19805 


► 


Years 


Figure  12  (A)  Definition  of  Systems  Engineering  Over  the  Years 
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Descriptive  Phrases  of 
Systems  Engineering 


Academic  Discipline 

Analysis 

Analytical 

Balance  of  all  System  elements 

Balanced  set  of  system  people 

Balanced  set  of  system  product 

Collaborative  Approach 

Combination  of  methods  &  tools 
thru  use  of  suitable 
methodological  process 

Comprehensive  Approach 

CostAssessment 

Creation  of  Alternatives 

Creation  of  Systems 

Decision  Making 

Designing  of  Systems 

Developmentof  information 

Document  Requirements  in 
Specifications 

Encompassing  the  entire 
technical  effort 


Evolve  and  verify 

Planning 

For  Large  Scale  and  Scope 

Policy  Making 

Formulation 

Post  Implementation 

Formulation,  Analysis  & 

Assessment 

Interpretation  of  propose£rocess  So|utions 

Identification  of  System  Goals 

Production  of  Systems 

Information  and  Knowledge 
Organization  &  Management 

Professional  Discipline 

Integration  of  the  '-ilities' 

Qualitative  formulation 

Integration  Process 

Quantification  of  System 
Goals 

Intellectual  Discipline 

Quantification  of  Systems 

Interdisci  plinary  Approach 

Quantitative  formulation 

Interpretation 

Requ  irements  Satisfaction 

Iterative  Process 

Process 

Life-cycle  View 

Resource  Deployment 

Maintenance  of  Systems 

Resource  Management 

Man  agemen  t  of  System 

RiskAssessment 

Configuration 

Robust  Approach 

Management  Process 

Satisfaction  of  Needs 

Management  Technology 

Satisfy  Customer  Needs 

Needs  Satisfaction 

Scientific  effort 

Solving  complex  System 
Problems 

System  Analysis 

System  Definition 

System  Management 
Procedure 

System  Performance 
Parameters  Identification 

System  Synthesis 

Technical  Effort  related  to 
Life  cycle  of  product/ 
system 

Technical  Process 
Testing 

Transform  Operational 
Need  to  System  design 

Translation  to  Work 
Breakdown  structures 

Verification  of  design 

Verification  Process 

Engineering  effort 

Evaluation 


► 


1990s 


Years 


Figure  13  (B)  Definition  of  Systems  Engineering  Over  the  Years 
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Balance  of  all  System  elements 

Complex  Systems 

Conformance  to  Schedule 

Cost  Effectiveness  Methods 

Creating  and  Executing  an 
Interdisciplinary  Process 

Customer  and  Stakeholders 
consideration 

Design  Synthesis 

Engineering  Discipline 

Engineering  of  Complex  Systems 

Evaluation 

Functional  Analysis 

Initial  definition  of  system 

Interdisciplinary  Approach 

Iterative  Process 

Life-cycle  View 

Needs  Satisfaction 

Non-Sequential  Process 

Non-Traditional  Engineering 
discipline 


Parallel  Process 

Requirements  Satisfaction 
Process 

Resou  rce  Allocation 

Satisfaction  of  Needs 

System  Analysis 

System  as  a  Whole 

System  Considerations 

System  Life  Cycle  Consideration 

Systems  Thinking 

Team  Approach 

Testing 

To  Guide 

Top-  Down  Approach 
Total  Operation 
Verification  Process 


2000s 


Years 


► 


Figure  14  (C)  Definition  of  Systems  Engineering  Over  the  Years 
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Figure  15  Authors  of  Cited  Definitions  of  Systems  Engineering  Over  the  Years 
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3.  Methodology 

In  the  Data  Gathering  Methodology,  the  chosen  approach  was  to  do  a 
survey  of  practicing  Systems  Engineers,  text  mining  of  classified  ads  for  Systems 
Engineers  and  review  of  journals,  articles  and  books. 

The  survey  of  practicing  Systems  Engineers  allowed  the  thesis  to  be 
initiated  in  two  ways.  First,  it  allowed  the  data  gathering  phase  to  be  initiated  (i.e. 
the  gathering  of  the  traits  that  make  a  good  Systems  Engineer).  Next,  the  survey 
allowed  for  the  initial  categorization  of  traits  in  order  to  acquire  the  traits  from  the 
classified  ads  and  the  literature  review. 

The  acquired  data  from  the  identified  sources  had  to  be  in  the  natural 
state  of  existence  for  the  application  of  the  modified  text-mining.  The  natural 
state  of  existence  here  refers  to  the  absence  of  any  possible  biasness,  i.e. 
skewedness  in  survey  questions,  propaganda  in  classified  ads,  etc.  Hence, 
acquiring  data  from  the  classified  ads  and  from  the  literature  review  was  deemed 
to  be  in  the  natural  state,  as  is  it  taken  that  there  are  no  ‘interference’  in  the 
contained  information. 

In  the  Analysis  of  Data,  the  chosen  method  had  to  include  a  measurement 
scale  to  add  some  degree  of  measurement  to  the  quantitative  traits  gathered.  For 
this,  Fuzzy  Logic  was  chosen. 

a.  Data  Gathering  Method 

Data  Gathering  involved  a  series  of  processes  as  depicted  in 
Figure  16.  The  sources  of  the  data  being  gathered,  i.e.,  literature  review,  surveys 
and  classified  ads,  had  to  be  representative  of  the  population  being  studied,  i.e., 
the  Systems  Engineering  community.  As  with  any  sociological  study,  it  was 
obvious  that  there  could  be  resident  errors  in  the  survey  results  if  the  process 
were  not  managed  from  the  start.  Some  of  the  inherent  errors  in  the  survey, 
modified  from  the  list  of  thirteen  sources  of  survey  errors  originally  outlined  by 
Demming  (1994)  in  Denzin  (1989),  are  shown  in  Table  5: 
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Table  5 


Possible  sources  of  error  in  surveys 


S/N 

Possible  Error  Source 
in  Survey 

Implication(s) 

Rectification 

1 

Variability  in  the 
response 

The  variability  in  the 
responses  would  mean 
that  there  is  no 
‘standard’  traits  list  that 
is  agreed  by  all  on 
what  makes  a  good 
Systems  Engineer 

Variability  in  the 
responses  is 
expected  in  the 
survey  as  the 
respondents  would 
have  different  levels 
of  experience  as 
well  as  operating 
from  a  different  level 
of  Systems 
Engineering  (Kasser 
and  Massie,  2001). 
For  this,  the  thesis 
will  take  into 
account  all  the 
offered  traits  and  not 
discard  any  outliers 
to  prevent 
misrepresentation 

2 

Biasness  arising  from  an 
unrepresentative 
selection  of  respondents 

There  could  be  some 
traits  not  being 
highlighted  for  a 
specific  industry 

In  the  selection  of 
the  practicing 

Systems  Engineers 
to  be  surveyed, 
effort  will  be  taken  to 
ensure  different 
industries  are  within 
the  sampled 
population 
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S/N 

Possible  Error  Source 
in  Survey 

Implication(s) 

Rectification 

3 

Errors  in  coding, 
processing,  editing,  and 
tabulation 

This  will  be  directly 
related  to  the  modified 
text-mining  activity. 
These  errors  will 
evolve  into  either  the 
stressing  or 
diminishing  of  the 
importance  of  certain 
traits.  Also,  certain 
traits  might  be  passed 
off  a  “ad  hoeing”8 

Effort  will  be  made 
to  ensure  that  if  the 
traits  given  require 
rephrasing,  their 
meanings  will  be  as 
close  as  possible  to 
the  phrases  in  the 
database.  However, 
this  is  a  potential 
source  of  inherent 
error.  To  reduce  the 
possibility  of  ad 
hoeing,  all  traits  will 
be  considered  and 
none  discarded 

4 

Errors  in  the 
interpretation  of  the 
survey  question  by 
respondents 
(misunderstanding, 
personal  bias) 

The  results  collected 
cannot  be  used  as  it 
will  not  synergize  with 
the  data  of  traits 

Clarification  replies 
to  the  respondents 
will  be  sent  to  verify 
the  replies  if  the 
questions  were 
misinterpreted. 
However,  this  is  a 
potential  source  of 
inherent  error 

5 

Differences  in  the  form 
of  survey  (face-to-face 
interviews,  telephone 
interview,  mail) 

Different  survey 
climates  will  produce 
differences  in  the  detail 
of  responses,  leading 
to  a  variation  in  the 
data.  However,  the 
effects  of  these 
differences  are  not 
known  (Denzin,  1989; 
Demming,  1994) 

The  survey  will  be 
standardized  in  the 
form  of  emails,  to 
reduce  any  possible 
sources  of  errors 

8  Ad  Hoc’ing  is  a  term  used  in  Denkin  (1 989)  from  Garfinkel  (1 967)  that  describes  the 
tendency  to  allow  a  response  to  be  coded  as  an  instance  of  a  category,  i.e.,  ‘act  as  if  the 
response  can  be  categorized  in  that  manner.’ 
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There  are  a  variety  of  sampling  strategies  available  for  use  (e.g., 
Theoretical  Sampling,9  Illustrative  Sampling,10  and  Triangulation. 

The  selection  of  the  sampling  strategy  required  the  strategy  to  be 
as  representative  as  possible  of  the  Systems  Engineering  community.  This 
needs  to  be  from  a  theoretical  and  realistic  (real  world)  point  of  view.  Otherwise, 
the  traits  gathered  will  not  be  representative  of  the  community. 

Triangulation  is  one  of  the  sampling  strategy  alternatives  to  validate 
the  gathered  data  (Denzin  and  Lincoln,  1994).  Triangulation  is  seen  to  be  the 
answer  to  the  dilemma  of  whether  a  specific  source  in  the  data  will  be  robust 
enough  to  provide  the  conclusions  of  the  thesis.  Hence,  the  combination  of 
multiple  methods,  empirical  materials,  perspective  and  observers  in  a  single 
study  is  best  understood  as  a  strategy  that  adds  rigor,  breadth,  and  depth  to  any 
investigation  (Denzin  and  Lincoln,  1994;  Flick,  1992). 

Triangulation  can  be  understood  from  four  definitions  (Denzin, 
1978):  Data,11  Investigator,12  Theory13  and  Methodological14  Triangulation;  a  fifth 
fifth  was  offered  by  Janesick  (1994):  Interdisciplinary15  Triangulation. 


9  Selecting  groups  or  categories  to  study  on  the  basis  of  their  relevance  to  the  research 
question  and  theoretical  position  (Mason,  2006). 

10  Relationship  between  sampled  contexts  and  phenomenon  and  the  population  of  interest  is 
illustrative/evocative  in  nature.  This  approach  seeks  only  to  provide  a  ‘flavor’  to  the  population 
(Mason,  2006). 

1 1  Use  of  a  variety  of  data  sources  in  a  study  (Denzin  and  Lincoln,  1 994;  Janesick,  1 994). 

12  Use  of  several  different  researchers  or  evaluators  (Denzin  and  Lincoln,  1994;  Janesick, 
1994). 

13  Use  of  multiple  perspectives  to  interpret  a  single  set  of  data  (Denzin  and  Lincoln,  1994; 
Janesick,  1994). 

14  Use  of  multiple  methods  to  study  a  single  problem  (Denzin  and  Lincoln,  1994;  Janesick, 
1994). 

15  Consideration  of  other  disciplines  to  study  a  single  problem  (Denzin  and  Lincoln,  1994; 
Janesick,  1994). 
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Figure  16  Data  Gathering  Process 


In  the  study  reviewed  by  Frank,  Frampton  and  Di  Carlo  (2007),  a 
‘termination  of  the  collection  of  data’  method  mentioned  by  Silverman  (2000), 
was  adopted.  The  method  articulates  the  establishment  of  categories 
(outstanding  repeated  elements)  on  the  analysis  of  raw  data.  As  such,  for  this 
thesis  the  data  sample  number  is  largely  determined  by  the  ‘establishment’  of 
these  categories. 

A  ‘modified’  meta  analysis16  methodology  was  adopted  in  the 
decision  for  the  source  of  the  data.  The  ‘modification’  here  relates  to  the  absence 
of  statistical  methods  to  analyze  the  data,  while  data  from  several  sources  was 
analyzed  to  draw  conclusions.  Multiple  sources  were  used  in  order  to  reduce  any 


16  Meta  Analysis  refers  to  the  analysis  of  the  results  of  several  studies  for  the  purpose  of 
drawing  conclusions  (Kaplan,  2004,  p.  281). 
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possible  bias  associated  with  a  single  source.  For  this  case,  a  survey  of 
practicing  Systems  Engineers,  text  mining  of  classified  ads  for  Systems 
Engineers  and  review  of  journals,  articles  and  books  were  carried  out. 

b.  Analysis  of  Data 

As  mentioned,  a  ‘modified’  meta  analysis  methodology  was  used  to 
analyze  data  from  several  sources.  The  adopted  methodology  omitted  the  use  of 
statistical  equations  for  measurements.  In  this  case,  the  error  of  effect  size 
associated  with  most  meta  analysis  studies  need  not  be  considered. 

Text  mining  tries  to  solve  the  crisis  of  information  overload  by 
combining  techniques  from  data  mining,  machine  learning,  natural 
language  processing,  information  retrieval,  and  knowledge 
management.  (Feldman  and  Sanger,  2006) 

Data  mining  deals  with  structured  databases  of  facts  (Hearst, 
2003).  The  goal  in  text  mining  is  also  to  uncover  unknown  information  (trends, 
patterns)  within  the  set  of  naturally  occurring  text. 

In  this  thesis,  the  conventional  text  mining  process  was  modified  by 
not  using  any  automated  system  in  the  pattern  recognition  of  the  naturally 
occurring  text  gathered.  The  possible  effect  of  this  would  be  ad  hoeing  (i.e., 
categorization)  of  the  traits. 

Based  upon  the  literature  review  (includes  queries  to  authors  and 
experts)  carried  out  on  text  mining,  there  has  been  no  study  carried  out  on  the 
traits  of  a  profession.  The  categories  formed  from  the  mined  text  will  clarify  the 
traits  of  a  good  Systems  Engineer. 

4.  Fuzzy  Logic 

The  last  (but  not  least)  category  researched  as  part  of  the  literature  review 
was  a  process  to  quantify  these  traits,  while  establishing  a  relationship  among 
them. 
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Hipparchus  used  a  six-point  brightness  scale  in  150  B.C.  as  a  means  for 
relative  comparison  of  star  magnitude.  Similarly,  social  scientists  use  a  variety  of 
scales  in  order  to  provide  a  means  of  measurement  of  every  conceivable  social- 
psychological  impression  (Lodge,  1981).  With  these  instances  in  mind,  the  thesis 
looked  at  possible  scaling  of  the  traits  gathered. 

The  original  idea  behind  fuzzy  logic,  as  advanced  by  Zedah  in  the  mid- 
1960s,  was  to  initiate  and  propagate  the  transition  from  traditional  mathematical 
modeling  in  engineering  to  a  new,  much  more  qualitative,  ‘rough’  modeling  using 
fuzzy  sets  and  fuzzy  methods  (Bandemer  and  Gottwald,  1995).  Fuzzy  Sets  were 
defined  by  Zedah  (1965): 

A  fuzzy  set  is  a  class  of  objects  with  a  continuum  of  grades  of 
membership.  Such  a  set  is  characterized  by  a  membership 
(characteristic)  function  which  assigns  to  each  object  a  grade  of 
membership  ranging  from  zero  and  one... 

Fuzzy  sets  offer  an  important  and  unique  feature  of  describing  information 
granules  whose  contributing  elements  may  belong  to  varying  degrees  of 
membership  (belongingness)  (Pedrycz  and  Gomide,  2007). 

Today,  fuzzy  logic  has  made  its  way  into  many  applications  in  common 
use,  from  home  appliances  to  automobiles  and  software. 

This  thesis  has  embraced  aspects  of  the  class  of  objects  (Categories), 
grades  (Scaling  Factors),  and  membership  (relationship  between  categories)  to 
produce  a  series  of  Fuzzy  Logic  scales. 
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III.  TRAITS  FINDINGS 


A.  SURVEY 

1 .  Overview  of  Survey  Conducted 

An  approval  was  obtained  from  the  Naval  Postgraduate  School  (NPS) 
Institutional  Review  Board  (IRB)  to  conduct  a  survey  on  the  traits  that  make  a 
good  Systems  Engineer.  The  approval  form  is  contained  in  Appendix  B. 

A  survey  was  conducted  of  33  practicing  Systems  Engineers  for  their 
opinions  as  to  what  makes  a  good  Systems  Engineer.  Most  of  those  surveyed 
had  more  than  seven  years  of  experience.  The  survey  was  conducted  via  email 
and  the  responses  tabulated  to  derive  naturally  occurring  categories.  Once  these 
categories  were  formed,  the  survey  ceased.  The  number  of  respondents 
acquired  was  sufficient  to  garner  the  categories  for  the  traits. 

2.  Approach  Taken  for  Survey 

The  end  state  of  the  survey  was  to  establish  a  set  of  categories  with  the 
traits  that  make  a  good  Systems  Engineer.  This  required  that  those  being 
surveyed  have  some  form  of  experience  as  Systems  Engineers  and  that  they  be 
‘been-there,  done-that’  kinds  of  persons,  creating  a  creditable  list  of  traits.  The 
process  for  the  survey  is  depicted  in  Figure  17. 
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Figure  17  Process  Flow  for  Survey 


B.  CLASSIFIED  ADS 

1 .  Overview 

The  classified  ads  were  used  as  a  source  of  traits  for  a  Systems  Engineer. 
These  ads  were  confined  to  those  available  on  the  Internet.  Forty  classified  ads 
were  used  in  this  case. 

2.  Approach  Taken 

There  are  hundreds  of  classified  ads  that  can  be  used  for  extracting  the 
traits  required  for  a  Systems  Engineer.  This  thesis  limited  the  ads  to  only  those 
available  on  the  Internet.  From  Silverman  (2000),  the  sample  size  used  was 
determined  when  categories  of  these  traits  naturally  formed.  Figure  18  shows  a 
nearly  identical  process  flow  of  acquiring  the  traits  of  a  Systems  Engineer  from 
classified  ads: 

The  question  tackled  in  this  area  of  research  was: 

What  are  the  traits  that  successful  companies/organizations  look  for  in 
their  employment  of  a  Systems  Engineer? 
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Figure  18  Process  Flow  for  Extracting  Traits  from  Classified  Ads 


C.  LITERATURE  REVIEW 

1 .  Overview 

The  literature  review  was  done  to  determine  the  taxonomy  of  traits  that 
have  been  investigated  by  other  authors.  The  search  for  these  recommended 
traits  spanned  the  various  sources  of  knowledge,  as  depicted  in  Figure  19 

2.  Approach  Taken 

The  literature  review  for  the  traits  of  a  Systems  Engineer  was  confined  to 
the  sources  of  knowledge  reviewed.  Some  of  the  sources  were  recommended  by 
the  practicing  Systems  Engineers  surveyed.  Figure  19  outlines  the  process  used: 
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D.  SUMMARY 

1.  Survey 

The  survey  uncovered  some  interesting  results  as  to  the  traits  that  make 
up  a  good  Systems  Engineer.  More  than  50%  of  the  respondents  agreed  that 
Oral  and  Written  communication  skills  were  trademarks  of  a  good  Systems 
Engineer.  Understanding  the  current  Systems  Engineering  tools  and  having  the 
ability  to  apply  the  knowledge  at  the  System  Level  with  interdisciplinary 
knowledge  are  also  required.  Figure  20  summarizes  the  counts  of  the  specific 
traits  of  a  good  Systems  Engineer  mentioned  in  the  collected  data. 


d) 

Q) 

C 

’5) 

c 

Lil 

</> 

E 

& 

w 

</) 

(0 

o 

(/> 


3 

Counts 


Figure  20  Summary  of  T raits  (Survey) 


47 


2. 


Classified  Ads 


A  Fuzzy  Logic  Scale  was  created  to  summarize  the  traits  desired  by 
employers.  The  scale  was  designed  in  accordance  with  the  number  of  years  of 
experience  and  was  scaled  from  1  to  10,  with  1  being  the  least  experienced  and 
10  being  the  most  experienced. 

At  all  levels  of  experience,  employers  desire  Systems  Engineers  to 
possess  good  oral  and  written  communications  skills,  coupled  with  the  ability  to 
be  a  team  player.  It  is  also  noticed  that  beyond  specific  levels  of  experience, 
certain  traits  are  desired.  For  example,  for  values  of  3  and  above  on  the  fuzzy 
scale  of  experience,  Interpersonal  Skills,  Analytical  Skills,  Systems  Thinking  and 
many  other  characteristics  are  sought  in  a  Systems  Engineer. 

3.  Literature  Review 

The  literature  review  for  the  traits  of  a  Systems  Engineer  saw  insignificant 
changes  from  the  1960s  to  today.  Figure  21  and  Figure  22  (pages  50  and  51 
respectively)  outline  the  summary  of  these  traits: 

E.  MERGING  OF  RESULTS 

1.  Baseline  for  Merging 

The  three  sources  (Classified  Ads,  Survey,  Literature  Review)  for  the  traits 
of  a  Systems  Engineer  were  merged  using  the  key  questions  of: 

What  makes  a  good  (successful)  Systems  Engineer? 

What  are  the  desired  traits  of  a  good  Systems  Engineer? 

2.  Essential  Traits 

Over  700  traits  were  gathered  from  the  three  sources  mentioned.  An 
amalgamation  of  the  sources  of  the  traits  was  done  and  the  counts  for  each 
particular  trait  received  were  used  as  the  axis  for  the  comparison.  A  fuzzy  scale 
was  then  created  to  have  a  high  scale  for  high  counts,  and  a  low  scale  for  low 
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counts.  This  is  shown  in  Figure  25  (page  54).  The  traits  were  grouped  to  have  a 
member  relationship  to  the  scale  of  the  level  of  experience. 

To  eliminate  any  possible  bias  in  the  classified  ads  fuzzy  logic  experiential 
scale,  an  amalgamated  list  of  traits  obtained  from  the  literature  review  and  survey 
was  compared  against  the  classified  ads  fuzzy  logic  experiential  scale.  This  is 
shown  in  Figure  23  (page  52). 
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Figure  21  Fuzzy  Logic  of  Traits  to  Years  of  Experience  (Classified  Ads) 
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Figure  23  Summary  of  T raits  by  Year  of  Publication  (Literature  Review) 
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Figure  24  Fuzzy  Scale  of  Amalgamated  List  (Survey  and  Literature  Review) 
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continuous  improvement 

Direct  technical  experience 
planning 

Engine  control  systems 
development 

Experience  Skills  at  Systems 

Generation  of  Military 
Specifications 

Global  Engineering  Organization 

Good  Engineering  Judgment 

Hardware  Experience 

Hazard  Analysis 

Healthcare  Standards 

Human  Factors 

Industry  and  Education 
Institutions  contacts 

Information  Manager 

Innovative 

Intellectually  Honest 

International  /  Intercultural 
adaptability 

Interviewing  and  questioning 

Keen  to  learn 

Knowing  when  to  Stop 

Knowledge  of  applicable 
codes  and  standards 

Knowledge  of  Customer's 
Profile 

Lead  a  diverse  team  of 
talents 

Learning  By  Experience 

Life  Cycle  Cost  Analysis 

Listening  skills 

Logistics/Ops  Engineer 

Looking  for  the  non  obvious 

Maintaining  Design  Integrity 

Maths  background 

Matrix  relationship 
understanding 

Monitoring 

New  Systems  Tools 

Open  Minded 

Operational  Analysis 

Opportunity  Management 

Pattern  Recognition 

Physics  background 

Pick  up  new  ideas  and 
information  quickly 

Planning  And  Organizing 
Skills 

Politics 

Process  Development 

Process  Engineer 

Process  Management  Skills 

Product  Knowledge 

Product  Safety 

Productization  of  Systems 

Quantitative  Skills 

Rapid  Prototyping  efforts 

Realization  System 

Resource  Allocation 

Responsible 

Scheduling 

Skeptical 

Social  Sciences 

Solutioning 

Standards  Familirisation 

Supplier  Management 

Survivability 

System  Planning 

System  Safety 

Systems  concepts 

Systems  development 
environment  experience 

Systems  Performance 

Systems  Synergy 

Technical  Expertise 

Technical  Integrity 

Technical  Investigations 

Technical  Leadership 

Technical  Manager 

Technology  Awareness 

Trend  Analysis 
Performance 

Understanding  of  Product 
Life  Cycle 

Understanding  of 
Relationship 

Understanding  Theory 
behind  problems 

Versatile 

Multi  Task 

Adaptable 

Asking  the  right  questions 

Facilitation  Skills 

Contract  Knowledge 

Functional  Definition 
and  Analysis 

Costing  (Analysis,  Knowledge, 
Management) 

Generalist 

Diverse  cross-functional  team 
environment  -  able  to  manage 

Hands  on  with 
Laboratory  Equipment 
and  Instruments 

Evaluation  of  Systems, 
Technical  Planning 

Implementation 

Process 

Human  Systems  Integration 

Initiative 

Information 
Technology  Fluency 

Negotiation  Skills 

Interactions  between 
systems 

Product  Development 

Technical  Reviewing 

Maintainability 

Total  Systems  (Consideration, 
Production) 

Management  Skills 

Objective 

Attention  to  Details 

Observant 

Broad  experience  across 
domains 

Optimization 

Change  Manager 

Planning  (Technical) 

Coaching  Skills 

Policy  Making 

Conceptual  Designing 

Realibility 

Continuous  Learning 

Requirements 
Specification  Writing 

Coordinator 

Security  Cleance 
(Secret) 

Development  of  Control 
Algorithms 

Technical  Glue  for 
Projects 

Engineering  Economics 

Engineering  Management 

Technical  Knowledge 

Oral  Communication  Skills 

Written  Communication  Skills 

Design  (Logical,  Physical, 
Product,  Reviews, 
Specifications,  Systems, 
Configuration,  Process) 

Subject  Matter  Expert  in  an 
Engineering  /  Technical 
discipline 

Systems  Engineering 
Process 

Project  Management  Skills 

Team  Manager  /  Leader 

Integration  (Function, 
Systems,  Technical) 

Systems  Thinking 

Team  Player 

Verification  and  validation 

Interpersonal  Skills 

Risk  Analysis  and 
Management 

Problem  Solving  Skills 

Testing 

Analytical  Skills 

Architecture  (Design, 
Product,  Systems) 

Computing  Experience  and 
Knowledge 

Trade  Studies  Designing 

Customer  Management 

Decision  Making  Ability 

Development  of 
Documentation 

Holistic  View  of  Things 

Software  Engineering 

Modeling  Skills 

Quality  (Assurance, 
Focus,  Management, 
Oriented) 

Systems  Engineering 
Tools 

Complex  Systems 

Interdisciplinary 

Knowledge 

Interface  Management 

Analysis  (Decision, 
Engineering, 
Requirements,  Systems, 
Alternatives) 

Certification 

Defense  Experience 

Mentoring  Skills 

Organizational  Skill 

Simulation  Skills 

Technical  Skills 

Analysis  of  Alternatives 

Creative 

Human  /  People 
Management 

1  5  10 

Low  Mid  High 


Figure  25  Fuzzy  Scale  of  Amalgamated  List  (Survey,  Classified  Ads  and  Literature  Review) 
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IV.  FUZZY  LOGIC  OF  TRAITS  OF  A  SYSTEMS  ENGINEER 


Can  a  model  be  used  to  understand  the  essential  traits  required  from  the 
list  of  varied  traits? 

How  large  is  the  gap  that  exists  between  a  novice  and  expert  Systems 
Engineer? 

A.  TYPES  OF  SCALES 

1.  Experiential  Scale 

The  fuzzy  logic  scale  for  the  experience  of  a  Systems  Engineer  takes  into 
account  industry  requirements  as  manifested  in  the  classified  ads.  The  number  of 
years  of  experience  mentioned  was  pegged  to  the  required  traits  in  the  classified 
ads.  With  these,  a  fuzzy  scale  was  created  with  the  number  of  years  of 
experience  being  scaled  from  1  to  10,  1  denoting  a  low  experience  level  and  10 
the  most  experienced  Systems  Engineer.  Figure  27  shows  the  experiential  fuzzy 
logic  scale  developed.  Within  the  scale,  an  adaptation  of  Moore’s  (2000)17 
definitions  of  Fat-Short18  and  Thin-Tall19  Systems  Engineers  was  used  to 
describe  the  different  types  of  Systems  Engineers. 

The  characteristic  nature  of  the  scale  showed  the  following: 

a.  Years  of  Experience 

The  experience  level  could  be  broken  into  specific  number  of  years, 
as  depicted  in  the  classified  ads.  These  ranges  are  shown  as  Scale  1  (1  year), 
Scale  3  (2-3  years),  Scale  5  (5-7  years),  Scale  7  (10  years),  and  Scale  10  (more 
than  15  years). 


17  The  term  was  originally  used  by  Mead  and  Conway  (1979)  to  describe  tall-thin  designers. 

18  Fat-Short  -  person  with  a  specialized  set  of  technical  skills  who  cannot  easily  integrate 
concepts  from  multi-disciplines. 

19  Thin-Tall  -  person  with  a  broad  technical  skill  who  can  easily  integrate  concepts  from 
multi-disciplines. 
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b.  Categories  of  Traits 

From  the  fuzzy  scale,  it  was  noted  that  certain  traits  were  expected 
at  each  scale  level.  On  the  other  hand,  Oral  and  Written  communication  skills 
and  the  ability  to  be  a  team  player  were  desired  traits  regardless  of  individual 
experience  level.  These  categories  can  be  seen  as  an  acknowledgement  that 
certain  traits  found  beyond  Scale  5  (5-7  years)  take  time  to  develop  within  the 
Systems  Engineer. 


c.  Membership 

Within  the  experiential  fuzzy  logic  scale,  there  is  a  member 
relationship  of  the  groups  of  traits  to  the  fuzzy  scale.  For  instance,  cost 
management,  total  systems  consideration,  mentoring  and  engineering  analysis 
have  a  relationship  to  a  scale  of  7  to  10  on  the  experience  scale.  This  gives  rise 
to  generic  membership  input-output  statements  such  as,  IF  INPUT  is  HIGH 
EXPERIENCE,  OUTPUT  is  cost  management,  total  systems  consideration, 
mentoring  and  engineering  analysis,  where  INPUT  (1,10).  These  logic 
expressions  are  thus  expressed  as: 

Table  6  Logic  expressions  of  Experience  Levels 


S/N 

INPUTS 

Symbol 

Values 

1 

Experienced 

E 

(7,10) 

2 

Mid-experienced 

M 

(3,6) 

3 

Novice 

N 

(1.2) 

Within  the  experiential  fuzzy  logic  scale,  there  is  a  member 
relationship  of  the  groups  of  traits  to  the  fuzzy  scale.  For  instance,  cost 
management,  total  systems  consideration,  mentoring  and  engineering  analysis 
have  a  relationship  to  a  scale  of  7  to  10  on  the  experience  scale.  This  gives  rise 
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to  generic  membership  input-output  statements  such  as,  IF  INPUT  is  HIGH 
EXPERIENCE,  OUTPUT  is  cost  management,  total  systems  consideration, 
mentoring  and  engineering  analysis,  where  INPUT  (1,10).  These  logic 
expressions  are  thus  expressed  as: 


Table  6,  creates  a  characteristic  function  as  shown  in  Figure  26: 


(Oral  /  Written  Communication  Skills  /  Team  Player) 


(E,  M,  N) 


Systems  Thinking  /  Testing  Skills 


Analytical  Skills  /  Handle  Product  Design  Specifications  /  Leader  /  Multi  Tasking 


Verification  and  validation  /  Complex  Systems  Handling  /  Interdisciplinary  Knowledge  /  Project  Management  Skills  / 

Specific  Domain  Knowledge 

Customer  Management  /  Focus 

Integration  (Function,  Systems,  Technical)  /  Systems  Engineering  Process 
Interpersonal  Skills  /  Requirements  Analysis  /  Risk  Analysis 


Documentation  /  System  Architecture 

Subject  Matter  Expert  in  an  Engineering  /  Technical  discipline  /  Trade  Studies  / 
Human  Systems  Integration 

Decision  Making  Skills  /  Policy  Making  /  Certification 

Manage  Teams  /  Organization  Skills  /  Standards  Familiarization 


Contract  Knowledge  /  Problem  Solving  Skills  /  System  Design  /  Adaptable  / 
Computer  skills  with  SE  Tools 


Quality  Management 

Modeling  /  Interface  Management 

J 

r  e  e 


j 


Total  Systems  Consideration  /  Production 

Evaluation  of  Technical  Plans  /  Evaluation 
of  Systems 

Engineering  Analysis 


Cost  Management 
Matrix  relationship  understanding 
Mentoring  management  staff 


e  (E,  M) 


Product  Development 
Process  /  Coaching  Skills 


Coordinating  Skills 


e  (M,  N) 
e  (M) 


Figure  26  Characteristic  Functions  of  the  Various  T raits 
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With  the  characteristic  functions  developed,  a  mechanism  for 
pegging  the  category  of  the  membership  of  the  trait  to  the  various  experience 
levels  (E,  M  and  N)  can  be  done.  This  will  allow  recruiters  to  know  the  level  of 
experienced  to  be  sought  when  a  specific  trait  is  desired. 

2.  Worth  of  Experience  Scale 

A  worth  of  experience  fuzzy  scale  is  simply  the  annual  salary  that  a 
Systems  Engineer  would  receive  commensurate  with  the  level  of  experience.  A 
survey  was  conducted  in  1996  by  WholeRoot  Economic  Research  Inc.  (30  Oct 
2008)  on  the  annual  salaries  of  Systems  Engineers,  based  on  the  level  of 
experience.  The  nominal  values  of  these  salary  ranges  were  calculated  based  on 
the  scaling  factor  (Naval  Center  for  Cost  Analysis  (NCCA),  Jan  2008)  obtained  in 
Year  2008  Dollars.  Figure  28  shows  the  fuzzy  scale  of  the  annual  salaries  to  the 
scaled  experience  level  of  a  Systems  Engineer. 

Figure  27,  used  in  comparison  to  Figure  28,  validates  the  observation  that 
Thin-Tall  Systems  Engineers  are  paid  more  due  to  their  experience  level. 

3.  Traits  Industry  Scale 

Certain  industries  might  require  certain  specific  and  essential  traits  for 
their  Systems  Engineers.  As  such,  an  attempt  was  made  to  generate  a  fuzzy 
scale  to  depict  the  scale  of  the  traits  required  of  Systems  Engineers  in  the 
respective  industries  that  had  their  classified  ads  sampled  in  this  thesis. 

It  was  noted  that  the  Research,  Defense,  and  Aerospace  industries 
required  a  higher  Traits  Level  Scaling  Factor  from  their  Systems  Engineers  (i.e., 
the  more  experienced). 
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Fat 

Thin 

Short 

Tall 

Product  Development 
Process  /  Coaching  Skills 

Coordinating  Skills 

Quality  Management 


Functional  Definition 


Modeling  /  Interface  Managemen 


IT  Skills  /  Software  Experience 


Technical  Skills  /  Attention  to  Details 


Documentation  /  System  Architecture 


Subject  Matter  Expert  in  an  Engine 
Human  S 


Contract  Knowledge  /  Problem  S 
Com  puter 


Systems  Thinking  /  Testing  Skils 


Analytical  Skills  /  Handle  Product  Design  Specification^  /  Leader  /  Multi  Tasking 


Verification  and  validation  /  Com  plex  Systems  Handling  /  Interdisciplinar; 

Specific  Domain  Knowledge 


Customer  Management  /  Focu$ 


Integration  (Function,  Systems,  Technical)  /  Systems  Engineering  Process 


Interpersonal  Skills  /  Requirements  Analysis 


Total  Systems  Consideration  /  Production 


-valuation  of  Technical  Plans  /  Evaluation 
of  Systems 


Engineering  Analysis 


Cost  Management 


Matri  x  relationship  understanding 


Mentoring  management  staff 


ering  /  Technical  discipline  /  Trade  Studies  / 
ystems  Integration 


Decision  Making  Skill  s  /  Policy  Making  /  Certification 


Manage  Teams  /  Organizat  on  Skills  /  Standards  Familiarization 


olving  Skills  /  System  Design  /  Adaptable/ 
skills  with  SE  Tools 


(  Knowledge  /  Project  Management  Skills  / 


/  Risk  Analysis 


Oral  /  Written  Communication  Skills  /  Team  Player 


1  3 

Low  Mid-Low 

1  year  2-3  years 


5 

Mid 

5-7  years 


7 

Mid-High 
1  O  years 


lO 

High 

>1  5  years 


Figure  27  Fuzzy  Logic  of  Traits  to  Years  of  Experience  (Classified  Ads)  With  Tall-Thin  and  Short-Fat  Categories 
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>USD$174.5 


USDS126.5  to  147.4 


USD$95.5  to  116.8 


USD$88  to  89.2 


USD$68.7  to  83.4 


USDS59  to  70.6 


1  3  5  7  10 

Low  Mid-Low  Mid  Mid-High  High 

Traits  Level  Scaling  Factor 


Figure  28  Fuzzy  Logic  of  Annual  Salaries  to  Years  of  Experience  Scale 


Pharmaceutical 
(Factor  5) 


Healthcare 
(Factor  5) 


Automotive 
(Factor  5) 

Industrial  Estate 

Engineering 

Architecture 

Agricultural 

Genetics 

(Factor  2) 

(Factor  4) 

(Factor  5) 

Electrical  and 
Electronics 
(Factor  8) 

Aviation 
(Factor  8) 


Research  and 
Technology 
(Factor  10) 


Defense  and 
Aero 

(Factor  9) 


1  3  5  7  10 

Low  Mid-Low  Mid  Mid-High  High 

Traits  Level  Scaling  Factor 

Figure  29  Fuzzy  Logic  of  Industries  to  Years  of  Experience  Scale 
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B.  APPLICATIONS  OF  SCALES 


1.  Academic 

A  survey  on  the  available  Systems  Engineering  Education  was  extensively 
covered  by  Vidale  (1970),  touching  on  education  institutions  having  Bachelor  of 
Science  (B.S.),  Master  of  Science  (M.S.)  and  Doctor  of  Philosophy  (Ph.D.) 
programs.  The  Experiential  Fuzzy  Logic  Scale  could  assist  academic  curriculum 
drafters  to  plan  and  chart  the  syllabus  relevant  to  industry’s  requirements.  This 
would  better  prepare  ‘learned’  Systems  Engineers  for  their  expected  role(s). 

2.  Industry 

The  Experiential  Fuzzy  Scale,  with  the  Worth  of  Experience  Fuzzy  Scale, 
can  be  adopted  as  a  means  to  gauge  the  types  of  traits  that  govern  the  level  of 
experience  required  in  hiring  a  Systems  Engineer,  commensurate  with  the  fuzzy 
scale  factor  to  the  annual  salary. 

With  the  characteristic  functions  developed  in  Figure  26,  a  mechanism  of 
identifying  the  category  of  the  membership  of  the  trait  to  the  various  experience 
levels  (E,  M  and  N)  can  be  done.  This  will  allow  recruiters  to  know  the  level  of 
experienced  to  be  sought  when  a  specific  trait  is  desired. 

3.  The  Systems  Engineer 

The  Experiential  Fuzzy  Logic  Scale,  coupled  with  studies  done  by  Baird 
(1971);  Frank,  Zwikael  and  Boasson  (1997);  Frank  (2000);  Augustine  (2000); 
Frank  and  Elata  (2005);  Davidz  (2005)  and  Sheard  (1996),  would  allow  a  novice 
Systems  Engineer  to  appreciate  the  required  traits  at  his  given  experience  level 
and  what  is  to  be  acquired  in  the  coming  years.  As  Covey  (2004)  emphasized  in 
his  book  on  the  Seven  Habits  of  Highly  Effective  People,  having  the  end  state  in 
mind  keeps  one  efficient.  Thus,  by  knowing  the  expected  traits  that  a  Systems 
Engineer  needs  to  acquire  at  each  stage  of  development,  the  novice  individual 
would  instinctively  seek  out  and  acquire  the  other  traits. 
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V.  ANALYSIS 


A.  FUZZY  SCALES 

1.  Industry  Requirements  of  Traits 

Comparing  Figure  25,  the  amalgamated  traits  Fuzzy  Scale,  to  the 
Experiential  Fuzzy  Scale  in  Figure  27  it  is  seen  that  most  of  the  high  score  traits 
in  Figure  25,  corresponding  to  a  high  count  rate  in  the  amalgamated  list  of  traits, 
are  required  by  industries  of  a  2-year  experienced  Systems  Engineer.  This 
implies  that  there  is  a  correlation  between  the  desired  traits  that  make  a  good 
Systems  Engineer  and  those  required  by  industries  of  their  Systems  Engineers. 
These  traits  mentioned,  to  name  a  few,  include  communication  skills,  design 
ability,  having  the  knowledge  of  the  Systems  Engineering  processes,  being  a 
team  player  and  leader,  having  the  problem  solving  skills,  systems  thinking 
ability,  analytical  skills  among  others. 

To  eliminate  any  possible  biasness  of  the  classified  ads  fuzzy  logic 
experiential  scale,  an  amalgamated  list  of  traits  obtained  from  the  literature 
review  and  survey  was  compared  against  the  classified  ads  fuzzy  logic 
experiential  scale.  It  was  also  observed  that  the  high  score  traits  in  Figure  24  are 
similar  to  those  mentioned  in  the  preceding  paragraph.  This  implies  that  those 
traits  much  desired  from  academics  and  practicing  Systems  Engineers 
correspond  to  those  required  by  industry  today. 

A  NASA  study  on  the  behaviors  of  Systems  Engineers  was  completed  in 
October  2008  (Williams  and  Derro,  2008).  An  observation  was  made  after  the 
study,  involving  the  survey,  interview  and  observation  of  38  of  their  highly 
regarded  practicing  Systems  Engineers.  The  observation  was  in  the  reflection  of 
the  behaviors  being  categorized  into  five  broad  ‘themes’,  namely,  leadership, 
attitudes  and  attributes,  communication,  problem  solving  and  systems  thinking, 
and  technical  acumen.  These  five  observed  ‘themes’  correspond  as  well  to  the 
observation  made  between  in  the  preceding  two  paragraphs,  i.e.,  there  is  a 
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correlation  between  the  desired  traits  that  make  a  good  Systems  Engineer  and 
those  required  by  industries  of  their  Systems  Engineers,  those  desired  from 
academics  and  practicing  Systems  Engineers. 

2.  Categories  of  Traits 

From  the  fuzzy  scale,  it  was  noted  that  there  were  traits  expected  at 
different  levels  of  scale.  On  the  other  hand,  Oral  and  Written  communication 
skills  and  “team  player”  personality  were  desired  traits  of  a  Systems  Engineer 
regardless  of  the  number  of  years  of  experience.  These  categories  can  be  seen 
as  an  acknowledgement  that  certain  of  these  traits  found  beyond  Scale  5  (5-7 
years)  take  time  to  develop  within  the  Systems  Engineer. 

B.  ON  TIME,  ON  BUDGET,  MEET  REQUIREMENTS 

1.  Getting  the  Traits  Right 

It  was  found  from  Miller  (2000,  as  cited  in  Honour,  2004)  that  of  60  Large 
Engineering  Projects  (LEP),  18%  did  not  meet  budget,  23%  did  not  meet 
schedule,  and  55%  did  not  meet  technical  objective  targets.  In  relating  these  to 
the  Experiential  Fuzzy  Scale  in  Figure  27  the  traits  for  Requirements  Analysis 
(embedded  in  Systems  Engineering  Process),  Cost  Management,  and  Project 
Management  Skills  can  be  correlated  to  Meeting  Technical  Objective  Targets, 
Budgetary  Targets,  and  Schedule  Targets,  respectively. 

The  Experiential  Fuzzy  Scale  in  Figure  27  shows  that  the  traits  of  Project 
Management  and  knowledge  of  Systems  Engineering  Process  (Requirements 
Analysis)  are  required  from  a  Systems  Engineer  as  early  as  the  2-year 
experience  point.  The  ability  to  do  Cost  Management  is  seen  to  be  required  only 
at  the  10-year  experience  point. 
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Though  there  could  be  many  other  variables  that  may  have  directly  and 
indirectly  contributed  to  the  findings  from  Miller  (2000)20  it  is  fair  to  say  that 
having  these  three  highlighted  traits  could  have  assisted. 

Today’s  industries  are  on  the  right  track  in  seeking  Project  Management 
Skills  and  Knowledge  of  the  Systems  Engineering  Process  as  essential 
requirements  for  a  Systems  Engineer  at  the  2-year  mark,  in  order  to  reduce  the 
possibility  of  failures  in  the  Scheduling  and  Requirements  Analysis  arena. 

C.  RELATIONSHIPS  BETWEEN  TRAITS,  EXPERIENCE  LEVEL  AND 

SUCCESS  LEVEL  IN  PROJECTS 

1.  Key  to  Success  in  Projects 

As  seen  in  the  varied  definitions  of  Systems  Engineering  and  in  the  traits 
required,  Team  Work  and  being  able  to  think  in  a  Multi-disciplined  mode  is 
essential  to  any  project.  As  such,  having  the  correct  levels  of  experience  among 
team  members  can  help  to  facilitate  execution  of  the  project.  It  was  noted  that 
the  power  and  coefficient  of  the  exponential  learning  curve  of  a  systems  engineer 
Is  governed  by  when  a  specific  trait  is  employed  in  a  project.  Mentioned  earlier, 
it  was  found  from  Miller  (2000,  as  cited  in  Honour,  2004),  that  of  60  Large 
Engineering  Projects  (LEP),  18%  did  not  meet  budget,  23%  did  not  meet 
schedule,  and  55%  did  not  meet  technical  objective  targets.  In  relating  these  to 
the  Experiential  Fuzzy  Scale  in  Figure  27  the  traits  of  a  Systems  Engineer  are 
mapped  to  the  three  elements  of  determining  project  success  for  this  thesis  ( 
Table  7):  Table  7  Elements  in  a  project  to  Traits  of  a  Systems  Engineer 
Matching 


S/N 

Elements  in  a  Project 

Traits  of  a  Systems  Engineer 
(From  Figure  21) 

1 

Satisfying  Requirements 

Requirements  Analysis 

2 

Meeting  Budgetary  Targets 

Cost  Management 

3 

Meeting  Schedule(s) 

Project  Management  Skills 

20  In  Miller,  2000,  project  performance  was  measured  by  two  sets  of  variables:  (1)  Ratings  by 
sponsors  of  the  technical,  economic,  social,  environmental.  Political  and  developmental 
performance  of  projects,  and  (2)  Cost  and  Schedule  results. 
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Honour  (2004)  further  emphasized  three  impacts  to  Systems  Engineering 
from  the  listed  findings  in  Miller  (2000).  shows  these  impacts,  mapped  to  the 
traits  of  a  Systems  Engineer: 


Table  8  Impacts  to  Systems  Engineering  to  Traits  of  a  Systems  Engineer 
Matching 


S/N 

Impacts  to  Systems 

Engineering 

Traits  of  a  Systems  Engineer 
(From  Figure  21) 

1 

The  need  for  a  structure  of 
leadership 

Leadership 

2 

Technical  difficulties  had  no 
statistically  linkage  to  the 
overall  project  performance 

Technical  Discipline 

3 

Technical  Excellence  is 

important  but  not  sufficient  for 
a  successful  project  outcome 

Technical  Discipline 

Learning  Curves  have  significantly  matured  since  the  1970s.  Learning 
Curves  have  and  are  still  occupying  an  increasingly  important  role  in  a  wide 
range  of  industries  (Towill,  1985).  Under  mentioned  are  some  statistics  on 
learning  (FitzGerald,  2005): 

Learn  by  doing  -  retain  75%  of  the  information  given 

Learn  by  reading  materials  -  retain  10%  of  read  information 

Learn  by  audio  [conference]  -  retain  a  mere  5% 

When  it  comes  to  in-house  training,  a  simulated  experience  is  better  than 
no  experience  at  all.  From  the  retention  percentages  by  FitzGerald  (2005),  we 
shall  assume  that  the  experts  (those  with  above  15  years  of  experience)  are  able 
to  retain  75%  of  the  essential  traits  listed  for  a  successful  project  listed  in.  This 
assumption  is  made  as  it  is  taken  that  experts  acquire  their  traits  from  having 
been  involved  in  many  projects  in  their  career  of  practicing  Systems  Engineering. 
These  experts  have  thus  have  reached  the  ‘optimum’  point  of  having  learned  the 


66 


tricks  of  the  trade,  thus  being  able  to  contribute  all  of  the  75%  that  they  have 
retained  by  doing  the  job  over  the  years.  We  further  assume  that  the  initial 
contribution  of  a  novice  Systems  Engineer  to  a  project,  based  on  the  respective 
listed  traits  are  at  15%.  The  15%  contribution  is  initiated  at  the  first  instance 
where  the  trait  appears  in  Figure  21 .  Raccoon  (1996)  covered  fifteen  forms  of  the 
learning  equation.  The  time  based  approach  in  acquiring  the  traits  of  becoming 
an  expert  Systems  Engineer  is  adopted.  This  is  due  to  the  fact  that  different  sets 
of  traits  are  acquired  over  the  years  of  experience  of  performing  Systems 
Engineering.  Hence,  the  exponential  learning  curve  is  adopted.  Thus,  merging 
the  retention  percentage  by  doing  from  FitzGerald  (2005),  the  essential  traits  for 
a  successful  project  from  Table  7  and  the  numeric  scales  to  which  these  traits 
are  tagged  to  in  Figure  21,  some  relationships  are  established. 

Figure  30  shows  the  exponential  relationship  established  between  the 
percentage  of  contribution  of  a  Systems  Engineer  (based  on  the  years  of 
experience)  to  the  number  of  years  of  experience  to  a  project. 

Learning  Curve  of  Traits 


Figure  30  Exponential  Relationship  between  contribution  of  a  Systems 
Engineer  to  the  number  of  years  of  experience 
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Using  the  coefficient  and  power  of  the  exponential  learning  curves  for  the 
requirements  analysis,  project  management  skills  and  cost  management,  a 
correlation  was  established  to  Figure  21  ’s  Experiential  Fuzzy  Logic  scales.  There 
is  a  direct  relationship  of  the  power  of  the  exponential  learning  curve  equation  to 
the  Experiential  Fuzzy  Logic  scale.  Conversely,  there  is  an  indirect  relationship  of 
the  coefficient  of  the  exponential  learning  curve  equation  to  the  Experiential 
Fuzzy  Logic  scale. 

From  the  correlations,  we  establish  the  relationship  of  the  power  and 
coefficient  of  the  learning  curve  exponential  equation  to  the  period  where  the  trait 
is  specifically  used.  For  example,  the  traits  of  Requirement  Analysis  and  Project 
Management  skills  are  initiated  at  the  two  year  point  (Figure  21)  and  for  Cost 
Management,  at  the  ten  year  point  (Figure  21 ). 

The  application  of  this  relationship  is  seen  in  the  appearance  of  the  three 
traits  (Project  Management  Skills,  Cost  Management  Skills  and  Requirements 
Analysis)  with  the  classified  ads.  Requirements  Analysis  and  Project 
Management  skills  are  required  by  recruiters  from  a  two  year  old  System 
Engineer  onwards.  As  for  Cost  Management  skills,  recruiters  are  only  looking  at 
those  with  ten  years  of  experience  to  start  having  this  specific  trait.  Upon 
extrapolating  the  learning  curve  of  the  Cost  Management,  it  can  be  seen  that  if 
recruiters  expect  this  trait  from  their  two  year  old  System  Engineer,  the 
contribution  to  the  project  with  this  trait  will  be  at  about  2%.  This  earlier 
expectation  of  the  recruiter  to  the  Systems  Engineer  will  allow  a  gradual  build  up 
of  the  trait  rather  than  a  steep  learning  curve. 
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VI.  RECOMMENDATIONS 


There  are  some  recommendations  made  from  the  thesis.  This  is  based 
upon  the  traits  being  desired  for  in  a  Systems  Engineer  and  the  years  of 
experience  of  the  Systems  Engineer. 

A.  EXPERIENTIAL  FUZZY  SCALE 

1.  Recruitment 

Figure  26  and  Figure  27  represent  a  tool  for  recruiters  of  Systems 
Engineers  to  identify  the  probable  characteristic  function  of  the  various  traits  that 
are  required.  From  the  characteristic  function,  the  recruiter  can  then  better 
indicate  the  level  of  experience  of  the  potential  candidates. 

B.  LEARNING  CURVE 

1.  Expected  Traits 

Learning  through  experience  is  exponentially  developed.  Figure  30 
illustrated  the  relationship  between  the  contribution  of  a  Systems  Engineer  to  the 
project,  in  relation  to  the  number  of  years  of  experience. 
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VII.  CONCLUSION 


From  the  surveys  and  literature  review  conducted,  it  was  found  that  a  list 
of  traits  was  emphasized  that  make  a  good  Systems  Engineer.  These  included 
the  ability  to  do  systems  thinking,  a  knowledge  of  the  Systems  Engineering 
process,  good  oral  and  written  communications  skills,  and  having  project 
management  skills.  These  can  be  found  in  Figure  24. 

The  traits  desired  that  of  a  Systems  Engineer  by  companies  and 
organizations  can  be  found  in  Figure  21.  The  traits  were  segregated  into  the 
years  of  experience  of  the  Systems  Engineer.  Evidently,  there  were  some  traits 
that  were  desired  regardless  of  the  experience  level.  These  traits  include  having 
good  oral  and  written  communications  skills,  the  ability  to  do  systems  thinking,  a 
leader,  analytical  skills  and  being  a  team  player. 

A  novice  Systems  Engineer  could  be  honed  on  the  traits  that  experienced 
Systems  Engineer  possess.  These  include  mentoring  management  staff,  being 
able  to  do  engineering  analysis,  evaluation  of  technical  plans,  and  evaluation  of 
systems.  The  gap  is  illustrated  in  Figure  21  in  contrast  between  the  traits  at  the 
scale  rating  or  1  and  3  (novice  Systems  Engineer)  against  7  and  10  (experienced 
Systems  Engineer). 

The  Fuzzy  Logic  model  was  adopted  with  the  learning  curve  to  depict  the 
traits  of  a  System  Engineer  with  the  years  of  experience  and  the  growth  of  some 
of  the  traits  respectively.  It  was  shown  that  the  Fuzzy  Logic  scale  was  able  to 
reference  the  traits  of  a  Systems  Engineer  against  the  years  of  experience, 
referencing  the  annual  salaries  to  the  years  of  experience  and  the  industry’s 
requirements  of  the  traits  to  the  years  of  experience  of  the  Systems  Engineer. 

The  fuzzy  scales  developed  represent  a  snapshot  of  the  various  traits  of  a 
Systems  Engineer  to  the  listed  variables  of  income  and  years  of  experience. 
Useful  as  recruitment  tools,  the  relationship  function  of  a  desired  traits  of  a 
System  s  Engineer  will  allow  the  recruiter  some  form  of  indication  of  the 


71 


membership  a  desired  trait  has  to  the  years  of  experience.  This  shows  the 
relationship  between  the  various  traits  of  a  systems  engineer  to  the  number  of 
years  of  experience. 

From  the  analysis,  and  that  of  the  October  2008  NASA  study  on  the 
behaviors  of  Systems  Engineers,  the  study’s  observation  correspond  to  the 
thesis’  analysis  that  is  a  correlation  between  the  desired  traits  that  make  a  good 
Systems  Engineer  and  those  required  by  industries  of  their  Systems  Engineers, 
those  desired  from  academics  and  practicing  Systems  Engineers. 

Also,  from  the  learning  curves  developed  for  three  of  the  traits,  as 
depicted  in  Figure  30,  it  is  shown  that  the  earlier  the  traits  are  expected  from  a 
Systems  Engineer,  the  less  steep  the  learning  curve  will  be  established. 

Ethnomethodological  studies  analyze  the  methods  on  how  people  (in  a 
social  environment)  form  their  commonsense  knowledge  of  the  environment 
(Garfinkel,  1984).  Given  the  setting  of  a  project  environment,  the  Systems 
Engineer  would  have  to  form  an  understanding  towards  ‘common  Systems 
Engineering  sense’.  For  this,  the  Systems  Engineer  would  have  to  adopt  the 
System  Engineering  processes,  with  the  use  of  the  trained  and  acquired  traits 
that  define  a  Systems  Engineer.  This  thesis  has  shown  that  some  of  the  traits  of 
a  Systems  Engineer  would  have  to  be  possessed  from  the  point  of  entry  to  the 
environment. 
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VIII.  FUTURE  EXPLORATIONS 


A.  TEXT  MINING 

1.  Usage  of  an  Automated  Process 

Use  software  to  do  the  text  mining  part  of  extracting  the  traits  of  a 
Systems  Engineer  for  a  more  refined  list. 

B.  USAGE  OF  ONE-ORGANIZATION  FINDINGS 
1.  NASA  and  Northrop  Grumman 

It  was  understood  during  the  research  that  NASA  and  Northrop 
Grumman  were  undergoing  major  restructuring  in  their  respective  Systems 
Engineering  Training  development.  Since  their  study  will  only  come  out  early  in 
2009  or  later,  it  is  envisaged  that  their  findings  would  be  beneficial  to  identify  the 
critical  traits  of  a  Systems  Engineer. 

C.  TRAITS  ACCORDING  TO  INDUSTRIES 
1.  Difference  in  Traits 

From  Figure  29,  it  is  noted  that  certain  industries  might  require  a  unique 
blend  of  traits  from  their  Systems  Engineers,  in  accordance  with  their  levels  of 
experience.  To  reduce  possible  bias  of  the  data,  more  samples  could  be 
obtained  from  a  different  list  of  industries.  In  this,  the  different  requirements 
(traits)  and  levels  of  experience  of  all  the  Systems  Engineers  required  could  be 
tabulated  to  further  verify  the  distinct  need  for  a  difference  in  the  level  of 
experience  in  each  industry. 
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APPENDIX  A. 


SYSTEMS  ENGINEERING  DEFINITIONS 


Table  9  Systems  Engineering  Definitions 


S/N 

Source 

Nature  of  Source 

Author 

Year 

Definition  of  Systems  Engineering 

1 

Systems  engineering 
principles  and  practice 

Book 

Kossiakoff, 

Alexander 

and 

Sweet,  Willaim 

N. 

2003 

The  function  of  systems  engineering  is  to  guide  the 
engineering  of  complex  systems.  Systems  engineering  is 
focused  on  the  system  as  a  whole-it  emphasizes  its  total 
operation. 

To  guide  -  "to  lead,  manage,  or  direct,  usually  based  on  the 
superior  experience  in  pursuing  a  given  course,"  "to  show 
the  way."  This  characterization  emphasizes  the  process  of 
selecting  the  path  for  others  to  follow  from  among  many 
possible  courses-a  primary  function  of  systems  engineering. 
System  -  "a  set  of  interrelated  components  working  together 
toward  some  common  objective."  Implies  a  multiplicity  of 
interacting  parts  that  collectively  perform  a  significant 
function. 

Complex  -  restricts  this  definition  to  systems  in  which  the 
elements  are  diverse  and  have  intricate  relationships  with 
one  another. 

The  function  of  Systems  Engineering  is  to  guide  (Lead, 
manage,  direct),  the  engineering  of  complex  systems. 
Systems  Engineering  is  focused  on  the  system  as  a  whole  - 
ot  emphasizes  its  total  operation.  It  looks  at  the  system  from 
the  outside,  that  is,  at  its  interactions  with  the  other  systems 
and  the  environment,  as  well  as  from  the  inside. 

2 

Fundamentals  of  systems 
engineering.  With 
economics,  probability  and 
statistics 

Book 

C.J.  Khisty 
and 

J.  Mohammadi 

2001 

Some  see  Soft  Systems  Thinking  as  part  of  SE,  others  draw 
the  distinction  between  hard  SE  and  Soft  Systems 
Methodology  (such  as  Khisty  and  Mohammadi  [2001]). 
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S/N 

Source 

Nature  of  Source 

Author 

Year 

Definition  of  Systems  Engineering 

3 

Engineering  fundamentals 
in  measurements, 
probability,  statistics  and 
dimensions 

Book 

K.C.  Crandall 
and 

R.W.  Seabloom 

1970 

Some  texts  stress  the  importance  of  economics  in  general 
engineering  [Crandall  and  Seabloom,  1970] 

4 

Systems  thinking,  systems 
practice 

Book 

P.  Checkland 

1981 

One  of  the  earliest  recognised  practitioners  of  modern-day 
SE,  Arthur  Hall,  suggests:  “Systems  engineering  operates  in 
the  space  between  research  and  business,  and  assumes  the 

attitudes 

of  both.  For  those  projects  which  it  finds  most  worthwhile  for 
development,  it  formulates  the  operational,  performance  and 
economic  objectives,  and  the  broad  technical  plan  to  be 
followed”  [Checkland,  1981:1301. 

5 

Handbook  of  Systems 
Engineering  and 
Management 

Book 

Andrew  P. 
Sage 

George  Mason 
University 
and 

William  B. 

Rouse 

Enterprise 

Support 

Systems 

1999 

Structure  -  Systems  engineering  is  management  technology 
to  assist  clients  through  the  formulation,  analysis,  and 
interpretation  of  the  impacts  of  proposed  policies,  controls,  or 
complete  systems  upon  the  need  perspectives,  institutional 
perspectives,  and  value  perspectives  of  stakeholders  to 
issues  under  consideration. 

Function  -  Systems  engineering  is  an  appropriate 
combination  of  the  methods  and  tools  of  systems 
engineering,  made  possible  through  use  of  a  suitable 
methodological  process  and  systems  management 
procedures,  in  a  useful  process-oriented  setting  that  is 
appropriate  for  the  resolution  of  real-world  problems,  often  of 
large  scale  and  scope. 

Purpose  -  The  purpose  of  systems  engineering  is  information 
and  knowledge  organization  and  management  to  assist 
clients  who  desire  to  develop  policies  for  management, 
direction,  control,  and  regulation  activities  relative  to 
forecasting,  planning,  development,  production,  and 
operation  of  total  systems  to  maintain  overall  quality, 
integrity,  and  integration  as  related  to  performance, 
trustworthiness,  reliability,  availability,  and  maintainability. 
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S/N 

Source 

Nature  of  Source 

Author 

Year 

Definition  of  Systems  Engineering 

6 

MIL-STD-499A 

Military  Standard 

US  DoD 

1974 

Systems  engineering  is  the  application  of  scientific  and 
engineering  efforts  to*  Transform  an  operational  need  into  a 
description  of  system  performance  parameters  and  a  system 
configuration  through  the  use  of  an  iterative  process  of 
definition,  synthesis,  analysis,  design,  test,  and  evaluation;* 
Integrate  related  technical  parameters  and  ensure 
compatibility  of  all  physical,  functional,  and  program 
interfaces  in  a  manner  that  optimizes  the  total  system 
definition  and  design;*  Integrate  reliability,  maintainability, 
safety,  survivability,  human  engineering,  and  other  factors 
into  the  total  engineering  effort  to  meet  cost,  schedule, 
supportability,  and  technical  performance  objectives. 

7 

MIL-STD-499B 

Military  Standard 

US  DoD 

1994 

An  interdisciplinary  approach  encompassing  the  entire 
technical  effort  to  evolve  and  verify  an  integrated  and  life- 
cycle  balanced  set  of  system  people,  product,  and  process 
solutions  that  satisfy  customer  needs.  Systems  engineering 
encompasses: 

(a)  the  technical  efforts  related  to  the  development, 
manufacturing,  verification,  deployment,  operations  support, 
disposal  of,  and  user  training  for  system  products  and 
processes; 

(b)  the  definition  and  management  of  the  system 
configuration; 

(c)  the  translation  of  the  system  definition  into  work 
breakdown  structures;  and 

(d)  development  of  information  for  management  decision 
making. 
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Source 

Nature  of  Source 

Author 

Year 

Definition  of  Systems  Engineering 

8 

International  Council  of 
Systems  Engineers 
(INCOSE) 

http://www.incose.org/practi 

ce/fellowsconsensus.aspx 

Web  Site 

INCOSE 

downloade 
d  on  27 
Aug  08 
last 

updated  02 
Oct  2006 

Systems  Engineering  is  an  engineering  discipline  whose 
responsibility  is  creating  and  executing  an  interdisciplinary 
process  to  ensure  that  the  customer  and  stakeholder's  needs 
are  satisfied  in  a  high  quality,  trustworthy,  cost  efficient  and 
schedule  compliant  manner  throughout  a  system's  entire 
lifecycle.  This  process  is  usually  comprised  of  the  following 
seven  tasks:  State  the  problem,  Investigate  alternatives, 
Model  the  system,  Integrate,  Launch  the  system,  Assess 
performance,  and  Re-evaluate.  These  functions  can  be 
summarized  with  the  acronym  SIMILAR:  State,  Investigate, 
Model,  1  ntegrate,  Launch,  Assess  and  Re-evaluate.  It  is 
important  to  note  that  the  Systems  Engineering  Process  is 
not  sequential.  The  functions  are  performed  in  a  parallel  and 
iterative  manner. 

9 

NASA  Systems 
engineering 
handbook(From 
http://en.wikipedia.org/wiki/ 
Systems_engineering) 

Book 

NASA 

1995 

Systems  engineering  is  a  robust  approach  to  the  design, 
creation,  and  operation  of  systems.  In  simple  terms,  the 
approach  consists  of  identification  and  quantification  of 
system  goals,  creation  of  alternative  system  design 
concepts,  performance  of  design  trades,  selection  and 
implementation  of  the  best  design,  verification  that  the 
design  is  properly  built  and  integrated,  and  post¬ 
implementation  assessment  of  how  well  the  system  meets 
(or  met)  the  goals." 

10 

Systems  Engineering 
Methods 
(From 

http://en.wikipedia.org/wiki/ 

Systems_engineering) 

Book 

Harold 
Chestnut 
Information 
Belbce 
Laboratory 
Research  and 
Development 
Center 
General 
Electric 
Company 

1967 

The  Systems  Engineering  method  recognizes  each  system 
as  an  integrated  whole  even  though  composed  of  diverse, 
specialized  structures  and  subfunctions.  It  further  recognizes 
that  any  system  has  a  number  of  objectives  and  that  the 
balance  between  to  optimize  the  overall  system  functions 
according  to  the  weighted  objectives  and  to  achieve 
maximum  compatibility  of  its  parts. 
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Nature  of  Source 

Author 
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Definition  of  Systems  Engineering 

11 

A  Methodology  For 
Systems  Engineering 

Book 

Arthur  D.  Hall 
pp  8  to  1 1 

1962 

Hall  [1962]  defined  systems  engineering  as  a  function  with 
five  phases:  (1)  system  studies  or  program  planning;  (2) 
exploratory  planning,  which  includes  problem  definition, 
selecting  objectives,  systems  synthesis,  systems  analysis, 
selecting  the  best  system,  and  communicating  the  results; 

(3)  development  planning,  which  repeats  phase  2  in  more 
detail;  (4)  studies  during  development,  which  includes  the 
development  of  parts  of  the  system  and  the  integration  and 
testing  of  these  parts;  and  (5)  current  engineering,  which  is 
what  takes  place  while  the  system  is  operational  and  being 

refined. 

12 

Systems  Engineering 
Methodology  for 
Interdisciplinary  Teams 

Book 

Wymore 

1976 

Systems  Engineering  is  the  professional,  intellectual  and 
academic  discipline  whose  primary  concerns  of  which  are 
the  analysis  and  design  of  large-scale,  complex,  man  / 
machine  systems. 

13 

Benjamin  S. 
Blanchard  and 
Wolter  J. 
Fabrycky 

2006 

(a)  Top-Down  approach  that  views  system  as  a  whole 

(b)  A  lifecycle  orientation  that  addresses  all  phases  to 
include  system  design  and  development,  production  and/or 

construction,  distribution,  operation,  maintenance  and 
support,  retirement,  phase-out,  and  dsiposal 
(c)  Initial  definition  of  system  requirements 
(d)  Interdisciplinary  or  team  approach  throughout  the  system 
design  and  development  process  to  ensure  that  all  design 
objectives  are  addressed  in  an  effective  and  efficient  manner 
(e)  Not  traditional  engineering  discipline 
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Nature  of  Source 

Author 
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Definition  of  Systems  Engineering 

14 

Systems  Engineering 

Book 

Andrew  P. 
Sage 

George  Mason 
University 

1992 

Systems  Engineering  is  a  management  technology  to  assist 
and  support  policy  making,  planning,  decision  making,  and 
associated  resource  allocation  or  action  deployment.  It 
accomplishes  this  through  quantitive  and  qualitative 
formulation,  analysis,  and  interpretation  of  the  impacts  of 
actions  of  action  alternatives  with  reference  to  the  user's 
needs,  values,  and  institutional  perspective.  Key  words  are 
Formulation,  Analysis  and  Interpretation.  In  fact,  all  of  the 
Systems  Engineering  can  be  thought  of  as  consisting  of 
Formulation,  Analysis,  and  Interpretation  of  the  various 
ingredients  at  what  we  call  phases  in  the  lifecycle  of  a 
system.  Systems  Engineering  is  the  design,  production,  and 
maintenance  of  trustworthy  systems  within  cost  and  time 
constraint. 

15 

Sailor 

1990 

Both  a  technical  and  management  process;  the  technical 
process  is  the  analytical  effort  necessary  to  transform  an 
operational  need  into  a  system  design  of  the  proper  size  and 
configuration  and  to  document  requirements  in 
specifications;  the  management  process  involves  assessing 
the  risk  and  cost,  integrating  the  engineering  specialties  and 
design  groups,  maintaining  configuration  control,  and 
continuously  auditing  the  effort  to  ensure  that  cost,  schedule, 
and  technical  performance  objectives  are  satisfied  to  meet 
the  original  operational  need. 

16 

Forsberg, 
Kevin  &  Mooz, 
Hal 

1992 

The  application  of  the  system  analysis  and  design  process 
and  the  integration  and  verification  process  to  the  logical 
sequence  of  the  technical  aspect  of  the  project  lifecycle. 

17 

Model-Based  Systems 
Engineering 

Book 

Wymore 

1993 

The  intellectual,  academic,  and  professional  discipline  the 
primary  concern  of  which  is  the  responsibility  to  ensure  that 
all  requirements  for  a  bioware/hardware/software  system  are 
satisfied  throughout  the  lifecycle  of  the  system. 
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Source 

Nature  of  Source 

Author 
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Definition  of  Systems  Engineering 

18 

System  Theoretic  concepts 
of  Systems  Engineering  - 
Proceedings  of  the 
European  meeting,  Vienna. 

1973  (Advances  in 
cybernetics  and  Systems 
Research) 

Book 

M'Pherson,  P. 

K. 

1973 

the  breadth  of  vision  and  the  unification  of  concepts  afforded 
by  systems  science  is  timely  because  of  the  iterdisciplinary 
framework  that  it  provides  both  for  comprehending  the 
increasing  complexity  of  today's  social-ecological  problems 
and  for  unravelling  such  problems  by  the  better  design  of 
man-organized  and  man-made  systems. 

19 

Optimisation  and 
Probability  in  Systems 
Engineering 

BookVan  Nostrand 
Reinhold  Co,  New 
York,  1970 

Rau,  J.  G. 

1970 

Consists  of  the  application  of  scientific  methods  in  integrating 
the  definition,  design,  planning,  development,  manufacture, 
and  evaluation  of  systems.  It  encompass  such  terms  as 
systems  approach,  system  functional  analysis,  system 
reliability  analysis,  task  analysis,  maintenance  analysis  and 
operation  analysis,  it  is  fundamentally  concerned  with 
deriving  a  coherent  total  system  to  achieve  a  stated  set  of 
objectives  subject  to  physical,  environment,  state-of-the  art 
andeconomical  constraints. 

20 

Introductory  Systems 
Engineering 

Book 

A.  K. 

Mahalanabis 
Professor 
Department  of 
Electrical 
Engineering 
Indian  Institute 
of  Technology, 
Delhi,  India 

1982 

Systems  Engineering  is  concerned  with  the  problem  of 
analysis  and  design  of  systems  using  general  terms. 
Systems  Engineering  has  to  do  with  Modelling,  Analysis, 
Simulation  and  Design. 

21 

Principles  Underlying 
Systems  Engineering 

Book 

Pitman  Publishing 
Corporation,  New 
York 

Dommaasch, 

D.  0.  and  C. 

W.  Laudeman 

1962 

Systems  Engineering  is  used  to  describe  an  integrated 
approach  to  the  synthesis  of  entire  systems  designed  to 
perform  various  tasks  in,  which  is  expected  to  be,  the  most 
efficient  possible  manner.  Systems  Engineering  is  used  to 
desctibe  an  approach  which  views  an  entire  system  of 
components  as  an  entity  rather  than  simply  as  an  assembly 
of  individual  parts. 

22 

Systems  Engineering 
Handbook 

Book 

Robert  E. 
Machol 

1965 

Systems  Engineering  is  concerned  with  the  design  of  a 
specific  class  of  systems. 
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Nature  of  Source 

Author 
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Definition  of  Systems  Engineering 

23 

EIA  /  IS 

EIA  /  IS  632 

Commercial 

Standard 

NA 

NA 

An  interdisciplinary  approach  encompassing  the  entire 
technical  effort  to  evolve  and  verify  an  integrated  and 
lifecycle  balanced  set  of  system  people,  product,  and 
process  solutions  that  satisfy  customer  needs.  Systems 
engineering  encompasses: 

(a)  the  technical  efforts  related  to  the  development, 
manufacturing,  verification,  deployment,  operations  support, 
disposal  of,  and  user  training  for  system  products  and 
processes; 

(b)  the  definition  and  management  of  the  system 
configuration; 

(c)  the  translation  of  the  system  definition  into  work 
breakdown  structures;  and 

(d)  development  of  information  for  management  decision 
making. 

An  interdisciplinary  collaborative  approach  to  derive,  evolve, 
and  verify  a  lifecycle  balanced  system  solution  which 
satisfies  customer  expectations  and  meets  public 
acceptability. 

24 

IEEE  1220 -Standard  for 
Application  and 
Management  of  the 
Systems  Engineering 
Process 

Standard 

Institute  of 
Electrical  and 
Electronics 
Engineers 
(IEEE) 

1994 

From  the  standard's  abstract  -  The  interdisciplinary  tasks, 
which  are  required  throughout  a  system’s  lifecycle  to 
transform  customer  needs,  requirements,  and  constraints 
into  a  system  solution,  are  defined.  In 
addition,  the  requirements  for  the  systems  engineering 
process  and  its  application  throughout  the 
product  lifecycle  are  specified.  The  focus  of  this  standard  is 
on  engineering  activities  necessary  to 
guide  product  development  while  ensuring  that  the  product  is 
properly  designed  to  make  it 
affordable  to  produce,  own,  operate,  maintain,  and 
eventually  to  dispose  of,  without  undue  risk  to 
health  or  the  environment. 
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Definition  of  Systems  Engineering 

25 

Unraveling  the  Systems 
Lexicon 

Paper  presented  at 
the  1996  INCOSE 
Symposium 

Dr  Jerome  G. 
Lake 

1996 

Systems  Engineering  is  an  interdisciplinary,  comprehensive 
approach  to  solving  complex  system  problems  and  satisfying 
stakeholder  requirements. 

26 

ANSI/EIA  632  As  a 
Standardized  WBS  for 
COSYSMO 

Paper  presented  at 
the  AIAA  5th 
Aviation, 
Technology, 
Integration,  and 
Operations 
Conference  (ATIO) 
26  -  28  September 
2005,  Arlington, 
Virginia 

Ricardo  Valerdi 
Massachusetts 
Institute  of 
Technology, 
Cambridge,  MA 
02139 
and 

Marilee 

Wheaton 

The  Aerospace 
Corporation,  El 
Segundo,  CA 
90245 

2005 

Systems  engineering  is  concerned  with  creating  and 
executing  an  interdisciplinary  process  to  ensure  that  the 
customer  and  stakeholder  needs  are  satisfied  in  a  high 
quality,  trustworthy,  cost  efficient  and  schedule  compliant 
manner  throughout  a  system's  entire  lifecycle.  Part  of  the 
complexity  in  understanding  the  cost  involved  with  systems 
engineering  is  due  to  the  diversity  of  definitions  used  by 
different  systems  engineers  and  the  unique  ways  in  which 
systems  engineering  is  used  in  practice. 

27 

DSMC,  Systems 
Engineering  Management 
Guide,  Defence  Systems 
Management  College, 
Superintendent  of 
Documents,  U.S. 
Government  Printing  Office, 
Washington,  D.C.  (1990, 

pp12) 

Management  Guide 

Defence 

Systems 

Management 

College 

1990 

The  application  of  scientific  and  engineering  efforts  to 

(a)  transform  an  operational  need  into  a  description  of 
system  performance  parameters  and  a  system  configuration 

through  the  use  of  an  iterative  process  of  definition, 
systensis,  analysis,  design,  test,  and  evaluation 

(b)  integrate  related  technical  parameters  and  ensure 
compatibility  of  all  physical,  functional,  and  program 
interfaces  in  a  manner  that  optimzes  the  total  system 

definition  and  design 

(c)  integrate  reliability,  maintainability,  safety,  survivability, 
human  engineering,  and  oher  such  factors  into  the  total 
engineering  effort  to  meet  cost,  schedule,  supportability,  and 
technical  performance  objectives. 
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28 

U.S.  Department  of 
Defense  Regulation  500. 2R 

Regulation 

U.S. 

Department  of 
Defense 
Regulation 

2002 

An  approach  to  translate  operational  needs  and 
requirements  into  operationally  suitable  blocks  of  systems. 
The  approach  shall  consists  of  a  top-down,  iterative  process 
of  requirements  analysis,  functional  analysis  and  allocation, 
design  synthesis  and  verification,  and  system  analysis  and 
control.  Systems  Engineering  shall  permeate  design, 
manufacturing,  test  and  evaluation,  and  support  of  the 
product.  Systems  Engineering  principles  shall  influence  the 
balance  between  performance,  risk,  cost  and  schedule. 
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Subject:  YOUR  PROJECT:  MATURITY  CURVE  FOR  SYSTEMS 

ENGINEERING 

1 .  The  NPS  IRB  is  pleased  to  inform  you  that  the  NPS  Institutional  Review 
Board  has  approved  your  project  (NPS  IRB#  NPS20080072-EP7-A). 

2.  The  NPS  IRB  was  originally  certified  by  BUMED  on  26  July  2002  and 
has  been  re-certified  until  30  August  2009. 
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Office  (Laura  Ann  Ikner-Price,  Halligan  Hall,  Room  20 IB)  at  the 
conclusion  of  this  project. 

4.  If  your  protocol  changes  at  any  time,  you  will  need  to  resubmit  your 
project  proposal  to  the  NPS  IRB. 

Under  32  CFR  219.1 16(d),  the  IRB  finds  that  the  requirement  to  describe  procedures  may 
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